DLinq vs ADO.NET Entity Framework

I’ve been following ADO.NET Entity Framework for over a year now and the truth is I was bit surprised when DLinq was released. From the initial look at things – it seemed as though the ADO.NET EF folks and the LINQ to SQL folks were operating in completely isolated environments – each producing their own copy of a wheel but with very different attributes, benefits, and even target audiences.

From what I’ve been reading lately though I came to understand that that isn’t the case. The ADO.NET Entity Framework has a different scope than LINQ to SQL. The ADOEF is responsible for three things:

• mapping a database schema to a model,
• creating a model
• allowing eSQL queries against that model.

Combined with Linq, which allows you to run LINQ queries against in-memory structures, you are free to issue LINQ queries against the generated ADOEF classes.

Furthermore with ADOEF you also have features like

• Entity inheritance – DLinq derived classes have a 1:1 table mapping structure. You get one class per table. EF on the other hand lets you create entities like Customer and EliteCustomer and SuperEliteCustomer that allow you to maintain progressively more information in the object model while still using the same normalized back-end relational store.
• Entity composition – You can have a single EF entity that is composed of data retrieved from multiple locations within the relational store. For example, you can have a single object that has properties that originated in 3 different tables.
• Composed Entity Updates Using EF, you can actually insert or update a single entity that originated from 3 different tables. If you modify three properties that originated from 3 different tables, then when the EF does an update for that data, it will issue 3 different queries. This is impossible to do in DLinq alone. The best you can do is manually create a transaction, manually add rows to 3 tables, and then call update. In short, EF preserves the object-oriented view of the data whereas the DLinq object-oriented view does half of that.
• Change schema – if you make a change to the schema in the underlying database in simple DLinq, you need to re-generate the classes, potentially screwing up any customizations you made to those classes. With EF, all you need to do is change the mapping specification and you can leave the Entity Data Model (EDM) completely untouched.

From the looks of it ADOEF combined with Linq promises to be the foundation of an extremely powerful persistence and business object framework.