Should I use Datasets or Entity Framework to transfer data via WCF services?

Question

I am working on a application design and investigating on passing data between WCF services and the ASP.NET web application. Options I am looking at are to either use "Datasets" or Entity Framework.

I have bunch of questions,

1. If I use Entity Framework to pass data, would it add more overhead to the WCF communication,
2. Is Datasets considered as "light weight" considering the communication overhead,
3. If i use Entity Framework, how can I maintain object models if I use stored procedures to return complex data?

Overall I need to figure out pros and cons of using these technologies.

Answer 1

Your question touches on the principles of service-oriented architecture (SOA). In SOA, a service should expose operations (methods) that apply to business objects through contracts. The business objects should be defined in a standard way which is why WCF uses WSDL and XML Schema to do this.

An SOA tenet is that business objects are shared through a schema and/or a contract but not as a specific implementation. By this priniciple, Dataset is a heavyweight, .NET specific, database-oriented object which should not be used to represent a business object. The Microsoft Patterns & Practices group apparently disregards SOA tenets since it shows how to use Dataset as Data Transfer Objects. Whether they're just promoting vendor lock-in or just trashing the whole concept of SOA is anybody's guess. If there is even the remotest chance your service will ever be consumed by a non-.NET client please do not use a Dataset.

If you decide on using the Entity Framework then I'd recommend using Code First to define the Entity Framework data model and just expose those "code first" business objects in your service. This SO question & answers provide a good discussion on using Entity Framework with WCF.

Answer 2

Are you really considering passing entire datasets up and down? This will destroy your object model and be more difficult to maintain, though I suppose you could implement the Repository pattern. Still, even just sending the changes you would need to do strange things like ensure you do not transfer the schema and perhaps using the compress option. But it is a very poor choice when compared to Entity Framework Code First with nice clean POCOs in a separate assembly and without any of the EF infrastructure polluting the DTOs.

EF should not add overhead as such but it depends how it is implemented and what data objects are being passed around. If you pass data into a context and use the correct option when SaveChanges is called such as SaveChangesOptions.ReplaceOnUpdate, only the changed entities will be updated. The queries executed are efficient so long as you are mindful not to lazy load stuff you don't need. You need to understand LINQ to entities well and batch your updates as you would any other potentially expensive method call. Run some tests with your database profiler running and try to improve the efficiency of your interactions with EF, monitor your IIS logs for data sizes and transmission times etc.

Datasets are not considered lightweight due to the need to encapsulate a schema and potentially somebody might make a mistake and send up a whole heap of data in multiple tables, including tables that are dependencies. These might need to be pulled in anyway either on the client or server - very messy! EF does support stored procedures in a sensible manner as they can be part of your model and get called when specific entities need to be saved. ORM will compliment your OO design and lead to cleaner code.

Also if you are doing something simple and only require CRUD without much in the way of business logic consider WCF Data Services.