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

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 开发者_StackOverflow中文版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

---

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.

---

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)

---

A. Check also NHibernate.

B. DataSet - the fastest and easiest, but you code a lot.

All the rest - there is a lot good in using ORM tools, but there is a lot of problems with 3 tiering with them.

(lazy loading is a problem to deal with, making a lot of big object trees that effect performance, caching is not as smart as possible)

So - it depends what is your major needs, and how much time you want to spend studying EL/LINQ or NHibernate before you start coding, b/c there IS a learning curve with this tools.

---

Best idea is to have opportunity to use both technologies at the same time. How can you do it? It is very simple with Repository pattern. At first you need create generic IRepository interface. Something likes this:

public interface IERepository<E>
{
    DbTransaction BeginTransaction();
    void EndTransaction();
    void Add(E entity);
    void Delete(E entity);
    int Save();

    ObjectQuery<E> DoQuery(string entitySetName);
    IList<E> SelectAll(string entitySetName);
    E SelectByKey(int Key);

    bool TrySameValueExist(string fieldName, object fieldValue, string key);
    bool TryEntity(ISpecification<E> selectSpec);

    int GetCount();
    int GetCount(ISpecification<E> selectSpec);
    int AddAndSave(E entity);

}

I prefer Entity Framework. I created 3 projects based on it. It works very fast, especially queries with paging. So, after you need create base generic class Repository with virtual methods what implement IRepository interface. And that’s all. Now you have very fast way to create DAl writing simple code like this:

public class MonthRepository:Repository<Month>
{

}

You have possibility to override all methods of base class and create access to DB using stored procedure where you need. And you can do with without changing code in other places. Your will still return the same type of entities but will get them in other way.

Reade more on http://www.codeproject.com/KB/database/ImplRepositoryPatternEF.aspx

---

NHibernate has the best overall mix of feature set, maturity, and support.

NHibernate, Entity Framework, active records or linq2sql

You should consider Linq support a priority for any solution you consider and your first two options above do not support Linq.