can wcf service be loosely decoupled

Question

To start with, I am a newbie in the world of WCF so pardon me if this sounds naive.

To my understanding , unlike ASP.NET based websites which use ADO.NET to communicate to the database, a silverlight based app always needs a WCF or RIA services to communicate to DB. We know that ASP.NET websites are not tightly coupled to the database model so one can run any stored proc using ADO.NET and view the results on a grid without knowing much about the resultant object model.

However, in a WCF or RIA service, you must always have have it in sync with the database entity model and cannot run any stored proc without its result pattern in the service. Therefore in someway, silverlight forces us to be tightly coupled with the database model.

Is there any way I can view the results of the stored proc on a grid irrespective of the number of times the proc get changed in the backend?

Answer 1

However, in a WCF or RIA service, you must always have have it in sync with the database entity model and cannot run any stored proc without its result pattern in the service. Therefore in someway, silverlight forces us to be tightly coupled with the database model.

Bzzzzt!!! Wrong answer!!

WCF services do not have to be tightly coupled to the database at all. In fact with a WCF service you can still implement the n-tier approach:

WCF end point -> calls through to business layer -> calls DAL -> calls database

The benefit of the WCF service is that it can be used to expose your business layer to a variety of disconnected loosely coupled clients (or consumers - they don't have to be UI clients). Everything that is exposed is done as an interface - the WCF service presents a contract which it guarantees to meet. The data objects returned via that interface can be anything i like (as long as it can be serialized across the WCF boundary). It doesn't have to be a DataTable or data objects that mirror my database structure.

I can't comment on RIA services though because i've not played with them. My understanding though is that they are just WCF services with a bunch of stuff generated for you for convenience, which means they may closely resemble your database structure. The way round this would be to just take a little more time and create your own WCF services. Other answerers may be able to elaborate more on that though :)

Edit: it appears that the actual problem is that your data retrieval mechanism is what is tightly coupled. There can be a number of ways to address this to isolate out the impact of making changes (note that this is not an exhaustive list):

• ensure your WCF calls return typed objects - even with the tight coupling to the database the object type remains the same, even though its internals can change (i.e. if you add another property), therefore you should require no change to the WCF interface when adding another column to your database table

• create a separate assembly which implements your data retrieval from the database. This becomes your DAL (D ata A ccess L ayer), put your LinqToSql stuff in there, this keeps it separate from the assembly that implements the WCF endpoints

• translate your data that is returned from the database into more generic and agnostic light weight data objects before they pass through the WCF boundary (Data Transfer Objects - DTOs)

• use a code generation tool (there are many) to generate your WCF interfaces based on your data object definitions