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.
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.