Question

I have just started evaluating whether or not I should be using OData influenced wcf data services or a standard WCF service application as the primary data source for Silverlight applications. I would like your thoughts on which is a better way under what situation/circumstance. What is lighter over the wire, easier to maintain, etc.

What I have gathered so far is:

• There are no Wcf data service templates in VS2010 that I know of, and I will need to create a asp.net web project first and then add a wcf data service, so its going to affect how I structure my projects.
• WCF Data services expose actual table names over the service. I don’t know yet of a way I can alias them and I’m not sure its a good idea to let the world know my table structure
• In a standard wcf service I will need to write linq queries against the EF or Domain service classes on the service side, while in a data service I can move that processing logic to the client.
• At first glance examining the classes exposed by the wcf data services seem easier to read and understand than those exposed by the EF

Do add your thoughts on this..

Thanks for your time.

Answer 1

There are no Wcf data service
templates in VS2010 that I know of,

Not project template – just an item template (for use inside an ASP.NET web site or web app). WCF DataServices are very tightly coupled to HTTP, so they only make sense in a web site/app.

WCF Data services expose actual table
names over the service.

NO ! At least not necessarily. The whole point of EF is that you can decouple the actual physical structure of your database from the (conceptual) model that gets exposed. You can totally rename entities, you can map several entities onto a single table, split up an entity over several tables, you can leave out attributes – anything you like!

At first glance examining the classes
exposed by the wcf data services seem
easier to read and understand than
those exposed by the EF

I doubt it – because by default, WCF Data Services will use a Linq-to-SQL or EF model as their basis, really. You can make that as simple or as complicated as you like.

Using a “regular” WCF service allows you to use the netTcpBinding for much faster performance (thanks to binary message encoding vs. textual messages for other bindings), when using your Silverlight 4 app in a company-internal network (doesn’t work for internet scenarios) – not something you can do with WCF DataServices.

The main difference in my opinion is the SOAP vs. REST difference:

• SOAP (traditional WCF) is oriented towards methods – you think and design your system in terms of methods – things you can do (GetCustomer, SaveOrder etc.)

• REST (the WCF DataServices approach) is all about resources, e.g. you have your resources and collections of resources (e.g. Customers) and you expose those out to the world, with standard HTTP verbs (GET, POST, PUT, DELETE) instead of separate specific methods that you define

So both approaches have their pros and cons. I guess the most important question is: what kind of app are you creating, and what kind of user audience are you targetting?

Update:

• for intranet / internal apps, I would think the advantage of a netTcpBinding (binary encoding) would justify using a classic WCF service – also for data-intensive apps, I personally find a method-based approach (GetCustomer, SaveCustomer) to be easier to use and understand

• for a public-facing app, using HTTP and being as interoperable as possible is probably your major concern, so in that scenario, I’d probably favor the WCF Data Service – easy to use, easy to understand URLs for the user