DLinq vs the ADO.NET Entity Framework

Caveat: The ADO.NET Entity Framework is, to the world outside Microsoft, nothing but speculation at this point. They will not have a CTP available for us to play with until August. That being said, however, ADO.NET EF has enough of an impact on those of us working with DLinq and SQLmetal-generated classes that I thought it was worth posting about.

ADO.NET Entity Framework Overview

Without going into too much detail, the ADO.NET Entity Framework is a brand new object-relational mapping system. It is more than just the mapper, however. Instead of mapping C# code classes directly to the underlying schema - which basically forces you to have C# conform to a relational model (ugly) - the ADO.NET EF allows you to create an Entity Data Model (EDM) that sits between your code and the underlying schema. This is combined with a mapping speciifcation that indicates how the model (XML) relates to the database (relational). When you combine the model with the mapping specification - you get the guts of the abstraction layer and the object-relational mapper. Here's where it stands out: the model supports inheritance, and the model can create single entities composed of data retrieved from multiple tables.

Using the EDM, you can have an entity called Customer that has a property called FirstName that is retrieved from the Customers table. However, you can also have a property on the Customer entity that contains a property called PrimaryPhone that actually comes from the CustomerPhoneNumbers table. The EDM allows you to create entities that are far closer to the real-life model of objects - using the mapping specification you can map a truly relational, 3rd-normal-form data store to a truly object-oriented class library.

Finally - once you have the model and the mapping specification done, you can use a new superset of SQL called Entity SQL (eSQL for short) that has additional hooks and functionality that are geared toward executing queries against an object model rather than relational data. There's no need for joins using eSQL - the entity created as a result of a join should already be described in the model - all you do is run your query against the entity described in the model.

DLinq vs the ADO.NET Entity Framework

So this is where the real issue starts. For those of us who have been working with DLinq and are creating applications and proofs of concept based on LINQ and Linq to SQL technologies (LINQ to SQL is what they're calling DLinq now I believe) are concerned. From the initial look at things - it seems 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.

That isn't entirely the case. The ADO.NET Entity Framework has a different scope than LINQ to SQL. The ADOEF (what I'll call the Entity Framework for now until a better acronym comes along). ADOEF is responsible for three things: mapping a database schema to a model, creating a model, allowing eSQL queries against that model. Where LINQ comes in is here: you can run LINQ queries against the in-memory structures represented by the ADOEF classes. In other words, once you have generated classes from a model using the EF tools, you are free to issue LINQ queries against those classes.

Here is what you can do with ADO.NET EF & LINQ that you cannot do (at least not without a truckload of work) with just DLinq alone:

• Entity inheritance - DLinq SQLmetal-derived classes have a 1:1 table mapping structure. You get one class per table. EF 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 in a 360-degree fashion whereas the DLinq object-oriented view is really only half of that.
• Change schema - if you make a change to the schema in the underlying database in simple DLinq, you need to re-run SQLmetal 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.

All in all, I am looking forward to the August CTP of ADO.NET v3, or LINQ to Entities to be more specific. Assuming the generated classes have what I need, LINQ to Entities promises to be the foundation of an extremely powerful persistence and business object framework.

tags: adonet3  framework  entity  adonet  entities  adoef  linq  dlinq  

links: digg this    del.icio.us    technorati    reddit