Danny Simmons Answers the Frequently Asked Question: Why Use the Entity Framework?
Updated 5/19/2008 and 5/20/2008 (see end of post and comments)
Traditional ADO.NET provides high-performance access to a wide range of relational database management systems (RDBMSs) with a common set of managed DbConnection, DbCommand and other Db... objects, as well as typed and untyped DataSets. DataSets were designed from the git-go to be serialized for n-tier service-oriented (formerly XML Web services) architecture. They carry current and original values with them across tiers to manage concurrency conflicts. LINQ to DataSet extends LINQ's Standard Query Operators to DataSets.
LINQ to SQL is an easy-to-use object/relational management (O/RM) tool that's designed for simple application scenarios with SQL Server 2000+ on the back end. LINQ to SQL v1 isn't suited to service-oriented architecture because its object graphs (entities with associations) can't be serialized with the Windows Communication Framework (WCF) DataContractSerializer. (The LINQ to SQL team appears not to have updated its entity classes to take advantage of the upgraded version of VS 2008 SP1 Beta's DataContract Serializer.) Several third parties have written wrappers or add-ons to make SQL Server operable in n-tier projects.
nHibernate is a mature, well-supported, open-source O/RM that offers plain old CLR objects (POCOs), persistence ignorance, great modeling flexibility and many third-party add-ins. nHibernate is widely used in n-tier, service-oriented .NET projects. A LINQ to nHibernate project is in early stage development. nHibernate is owned by Red Hat Middleware LLC and licensed under the Lesser GNU Public License (LGPL.) Ayende Rahien (Oren Eini), the author of Rhino Mocks, is a principal contributor to nHibernate.
There are 40+ commercial and open-source third-party O/RM tools for .NET. LLBLGen Pro, Genome and EntitySpaces are three examples of commercial O/RM tools that implement LINQ.
So an obvious issue for data-oriented .NET developers is should I use an O/RM and, if so, which one should I choose as my "standard O/RM?" Few independent developers or development teams can afford the time to gain expertise with the ins and outs of multiple, highly complex O/RM tools, such as nHibernate.
Danny Simmons' Why use the Entity Framework? post of May 16, 2008 briefly compares the ADO.NET Entity Framework (EF) with traditional ADO.NET and DataSets, LINQ to SQL, and nHibernate. However, it's his comparison with nHibernate that contains the most important reason for .NET developers to choose EF:
The EF was specifically structured to separate the process of mapping queries/shaping results from building objects and tracking changes. This makes it easier to create a conceptual model which is how you want to think about your data and then reuse that conceptual model for a number of other services besides just building objects.
Long-term we are working to build EDM awareness into a variety of other Microsoft products so that if you have an Entity Data Model, you should be able to automatically create REST-oriented web services over that model (ADO.Net Data Services aka Astoria), write reports against that model (Reporting Services), synchronize data between a server and an offline client store where the data is moved atomically as entities even if those entities draw from multiple database tables on the server, create workflows from entity-aware building blocks, etc. etc.
Not only does this increase the value of the data model by allowing it to be reused for many parts of your overall solution, but it also allows us to invest more heavily in common tools which will streamline the development process, make developer learning apply to more scenarios, etc. So the differentiator is not that the EF supports more flexible mapping than nHibernate or something like that, it's that the EF is not just an ORM--it's the first step in a much larger vision of an entity-aware data platform. [Emphasis and formatting added.]
As Danny notes, EF is the preferred back-end for ADO.NET Data Services, which in turn will become the on-premises version of SQL Server Data Services (SSDS). EF also is the preferred back end for ASP.NET Dynamic Data. The Live Mesh team is working with the Astoria Folks to incorporate "Astoria Offline," which combines ADO.NET Data Services and the Microsoft Sync Framework, into their fledgling online/offline desktop. Synergy with current and future Microsoft applications, tools and platforms is the most important reason to choose EF.
- John Papa agrees in his Why Use the Entity Framework? post.
- Julie Lerman seconds the motion in Danny Simmons on "Why use the Entity Framework?" - A must read.
- Jonathan Carter weighs in with Entity Framework comparisons.
- Rob Eisenberg, an nHibernate proponent, disagrees in Why EF?
Update 5/19/2008: Frans Bouma posts a "Why not to use the Entity Framework" treatise as Why use the Entity Framework? Yeah, why exactly?
Update 5/20/2008: More doubters:
- Jeremy Miller objects to missing persistence ignorance in What Dan Simmons forgot to tell you about the Entity Framework.
- Greg Young shows his dislike of a single model for reporting, searching and transactions in EF Long Term Plans.
- Jimmy Bogard shares Greg Young's concerns in More Entity Framework thoughts.
- Evan Hoff sees a problem with comparing "the long-term vision" to nHibernate in On Comparing Current Tools to Futureware.
Julie Lerman posted this link to Bloglines citations of Danny's post in her Responses to Danny Simmons "Why Entity Framework" post of May 20, 2008.
Atom 1.0 site feed
7 comments:
Dear Roger,
Please don’t be upset, but I don’t share your opinion in your statement „DataSets were designed from the git-go to be serialized for n-tier service-oriented (formerly Web service) architecture…“. First of all service orientation is no evolution of web services. Web services are a technical interface. Service orientation is a mind setting and has to do with how you design your interface and how you shape units of work. Second the DataSet was never ment to be put on the wire or be a first class citizen in a professional n-tier design. If yor google … ah live search … for the topic you’ll see that it violates n-tier principles (System.Data outside the DAL) and is not applicable to any form of a Domain Model and serialized non-webservices-conform (it writes its own schema instead of expressing it in the WSDL – which also violates the service oriented tenets stated by Don Box - “contract sharing”).
Regards,
Daniel Fisher | devcoach
EntitySpaces doesn't implement Linq. The O/R mappers who have a linq provider (not all of them implement Linq in full like we do, most implement a subset and not advanced cases)
- LLBLGen Pro (beta, out in 2 weeks)
- Genome
- Vanatec Open Access
- Opf3
- XPO
Although I haven't been investing a lot of time in the EF yet, I feel very confident with LINQ to SQL - it feels like a very transparent API and performance is incredible (in particular with compiled queries). It'll be the natural choice for projects featuring simpler data models.
I agree that LINQ to SQL feels like a version 1.0 release (not bashing the team, just realizing that several important requests didn't make it in the current version).
LINQ to SQL is nice for a more direct 1:1 mapping between entities (i.e. your data model) and your domain model(s) represented by business objects; when the two becomes more disconnected, the entity mapping in EF feels like a more elegant approach. If you need information from several entities represented in a business object, LINQ to SQL basically forces you to do micro management; the EF can represent those entities as a single model.
Again, it's possible to write a layer of adapters between your LINQ to SQL entities and business objects (i.e. represent several entities as a single unit), but that feels like reinventing the wheel (just use EF then).
I've been searching for performance comparisons between LINQ to SQL and EF. Recalling the betas of LINQ to SQL, that framework was definately benchmarked to the extreme and according to blog posts from the team members, high performance was critical (their work is highly appreciated).
Jim, with that in mind, how about extending the benchmarks you've implemented for LINQ to SQL with EF equivalents?
As the EF lends itself just as easily to the cache cloning pattern (thus, performance is only really relevant when actually going to the datastore for entities), it could be nice to see just how big a difference there is between the frameworks (if any).
It's great that the EF is becoming a cornerstone in many of the Microsoft products. Hopefully, it'll be one of those decisions to celebrate in the coming years.
Use the right tool for the task at hand. Looking forward to more information on the subject.
Anders Borum / SphereWorks
@Daniel,
You're right to correct my Web Services/SOA analogy and I've struck SOA. DataSets appeared at the height of Microsoft's "XML Web Services mania" and compatibilty with *.asmx Web services was a crucial element of their design. Persistence as XML documents also was useful.
That said, I didn't advocate using DataSets. I don't recommend them for any production application for the reasons you state.
--rj
@Frans,
See the "EntitySpaces to Support LINQ to SQL Libraries in Next Release" topic of LINQ and Entity Framework Posts for 5/7/2008+
It might have been a stretch to say EntitySpaces implements LINQ, but their inclusion of System.Data.Linq and System.Data.Linq.Mapping libraries comes close enough for me.
There's no question that your implementation supports advanced cases.
@Anders,
I'm in the midst of doing some performance comparisons between EF, LINQ to SQL, DbDataReader. EF tests will include EntityDataReader, Entity SQL and LINQ to SQL tests with and without compiled queries.
I'm hesitant to publish them at the moment because EF is still in beta.
@roger: if consuming an IEnumerable to fill a datastructure counts as supporting Linq, I think we're not doing the developers who are looking for linq supporting frameworks a favor.
I read the linked post, but I immediately wondered: why would I use that with entityspaces: why would I need entityspaces if I have to design my model first with linq to sql and it only works on sqlserver anyway?
Post a Comment