New .NET 3.5 Project: Which DAL technology to use?

Question

I am preparing a new Windows project and wonder what kind of DAL technology to use. Originally I was looking for something simpler to not spending too much time on building it. But I understand also that it has to be efficient and scalable in the long run.

I plan to use WPF (MVVM) Client and WCF Service on a 3 Tier system.

Just to sum up all the existing technologies I am familiar with:

DataSets

PRO: Might be a bit old fashioned, but very easy to use and let the most parts to be auto generated for you. One powerful aspect about datasets are the ease of traversing related data through the Relations. Also in a way its disconnected from database and might simplify the updates by taking care of timestamps automatically. Includes validation.

CONTRA: Quite old fashioned. Some consider them as no real business objects/Models but just a mirror of your SQL data tables. Passing them between WCF Service/Client might be more difficult than self created business objects.

Enterprise Library 4.1 - Data Access Block

PRO: The DAL is beautifully put into a Factory pattern. It takes care of connection opening and closing automatically. Very easy to use for most part. It supports both dataSets and normal SQL Sps to create your own Business objects. As part of an ongoing Framework it can be much more efficient to use in combination with rest of the Enterprise Library for an efficient end product.

CONTRA: ??

Linq to SQL

PRO: Auto creates the SQL tables into business objects. Easy to CRUD. Theoretically a very nice way to do it.

CONTRA: Having played around with it when it came out, I found it flaky and sometimes instable. It is already considered a dead technology after Microsoft announcement that Entity Framework 4.0 - as part of .NET 4.0 - will be Microsoft recommended way. Only few bug fixes are too be expected in .NET 4.0 but no more feature extending plans.

Entity Framework 4.0

I don't know anything about it, but only that it will eventually replace everything else as on .NET 4.0. I am also tempted to use it, however since its still in BETA, I wouldnt be able to go that way yet.

I am very tempted to use Enterprise Library 4.1 - Data Access Block and to create my own business objects. The big Con is that it will take more time to create the DAL. Unless someone can convince me of using DataSets through the Data Access Block instead.

What are your comments and ideas? Many Thanks, Kave

Answer 1

You mention Entity Framework as part of the "contra" for the Linq to SQL option, but you should consider it in place of Linq to SQL -- it provides pretty much the same functionality plus more. For projects with smaller databases it definitely provides a lot of bang for the buck. It can be challenging in EF to manage the context for larger databases, and schema changes can cause things to break, but these challenges are there with any data access approach.

The biggest con for EntLib, in my mind, is that you are still rolling your own data objects. The Enterprise Library takes away a lot of the plumbing code from a straight "old-school" ADO.NET implementation, which is nice, but it doesn't generate data objects for you that can be used out of the box for LINQ querying.

Answer 2

We prevously used DataSets with EntLib 4.1 Data Application Block.

We now use Entity Framework. We have achived a massive improvement in productivity with Entity Framework compared with EntLib 4.1. (Progam the data layer for 80 tables in 10 hours instead of 80)

Entity Framework 4 is still in Beta, but if it is a while before your project goes live, I would go with EF 4. You get the productivity of an ORM at the same time the flexibility of using POCO (Plain Old Clr Objects)