ADO.NET实体框架引发争论
作者 Abel Avram译者 朱永光 发布于 2008年6月9日 上午3时22分
Danny Simmons——一个在ADO.NET实体框架（Entity Framework，EF）项目中的微软开发人员，他最近发表了一个对实体框架和其他数据访问解决方案比较的博客帖子。在和传统的ADO.NET及LINQ to SQL比较之后，Danny又把实体框架和nHibernate进行比较，这就引起了其他开发人员的反对。下面是Danny的帖子的摘录：
在EF和nHibernate之间最大的不同是，实体数据模型（Entity Data Model，EDM），以及我们基于这个东西构建的需要长久运行的数据平台。EF通过了特别的构造，将查询/形成结果的映射过程，与构建对象和变更跟踪分离开来。这种方式让创建概念模型变得更为容易，而概念模型使你可以考虑如何实现数据，以便随后能在其他很多包含了这些构建对象的服务中重用。长期以来，我们把EDM这样的思想融入到多个其他微软产品中，以至于假如你拥有一个实体数据模型，你可以基于这个模型自动创建面向REST的Web Service（ADO.NET Data Service，即Astoria）；可以基于这个模型编写报表（Reporting Services）；可以在服务器和脱机客户端存储库中同步数据，这些数据可以作为实体进行原子性地移动，就算这些实体是从服务器上的多个数据库表中抽取而来；可以从实体感知的构建部件中创建工作流；等等，等等……所以，所谓的不同点不是EF比Nhibernate能支持更复杂的映射功能或其他类似的东西，而是在于——EF不仅仅是一个ORM，它是在基于实体理念的数据平台中庞大愿景中的第一步。
作为回应，Frans Bouma，LLBLGen Pro的主创人员，一个微软MVP，在它的帖子中写到：
我不同意这种说法：一个像Danny Simmons这样工作于实体框架中如此久的人，这样的人怎么能忽略这样一个事实——任何O/R Mapper都是针对实体理念的。在他最后一句话中所描述的东西，实际上是一个单一目的的O/R Mapper：就是让开发人员能在OO语言中使用实体实例，并把这些实例保存到如关系数据库这样的非OO环境中，反之亦然。假如所有的东西就是抽象的实体模型和它的投射，那么更大的愿景是什么呢？也许工具？它让开发人员创建这些投射和在应用程序代码中调用O/R Mapper服务根据容易。
Jeremy D. Miller，一个.NET开发人员和构架师，在他的博客中说到Danny Simmons：
他在比较NHibernate和实体框架过程中遗漏了一个重要的事实。实体框架对你的应用程序具有很强的入侵性，而Nhibernate没有。NHibernate让我能使用POCO的方式来对业务过程进行建模而无需知晓数据库。而，实体框架却要我把EF的基础结构直接加入到我的业务对象中。
Danny Simmons提到的为其他目的（如报表）而使用EDM的好处，Greg Young——一个微软的MVP，在他的博客上对其进行了评论
一个单一的模型不可能适应你的应用程序里包括事务行为、搜索和报表在内的所有方面……可以举出很多这样的内容来。如果你基于你的事务模型来创建报表，那么你就会遇到麻烦！
Jimmy Bogard，一个Headspring Systems的高级顾问，也在他的博客中回应到：
我认为把数据模型共享给你边界外的任何人，是错误的（参看Evans，Domain-Driven Design）。把概念模型或EDM或其它我们以任何名字称呼它的东西共享出来也是错误的。
我从来不把域对象直接通过服务暴露出来。这是对我尽量创建的封装的一种侵害。
如果任何人想要一个SSRS【译者注：SQL Server Reporting Service】，那么我会给他们一个单独的报表数据库——为报表所需而定制的。我不希望报表的关注点影响了我们的事务关注点。一个映射层不能解决这样的问题，但类似SSIS【译者注：SQL Server Integration Service】这样的产品却可以。你想要报表？好，这里有你需要的只读视图，每小时、5分钟、每天或随时进行更新。
所以，现在的问题是：ADO.NET实体框架是否已经不仅仅是一个O/R Mapper了，以及它如何和nHibernate进行比较？很多人倾向于认为EF是一个简单的O/R Mapper，并认为它相对于nHibernate而言缺乏很多特性。另外一方面，Danny Simmons说微软刚刚开始开发EF，他们的计划是未来要超越当前的O/R映射功能。
