一个在ADONET实体框架（Entity FrameworkEF）项目中的微软开发人员Danny Simmons他最近发表了一个对实体框架和其他数据访问解决方案比较的博客帖子在和传统的ADONET及LINQ to SQL比较之后Danny又把实体框架和nHibernate进行比较这就引起了其他开发人员的反对下面是Danny的帖子的摘录
在EF和nHibernate之间最大的不同是实体数据模型（Entity Data ModelEDM）以及我们基于这个东西构建的需要长久运行的数据平台EF通过了特别的构造将查询/形成结果的映射过程与构建对象和变更跟蹤分离开来这种方式让创建概念模型变得更为容易而概念模型使你可以考虑如何实现数据以便随后能在其他很多包含了这些构建对象的服务中重用长期以来我们把EDM这样的思想融入到多个其他微软产品中以至于假如你拥有一个实体数据模型你可以基于这个模型自动创建面向REST的Web Service（ADONET Data Service即Astoria）可以基于这个模型编写报表（Reporting Services）可以在服务器和脱机客户端存储库中同步数据这些数据可以作为实体进行原子性地移动就算这些实体是从服务器上的多个数据库表中抽取而来可以从实体感知的构建部件中创建工作流等等等等……所以所谓的不同点不是EF比Nhibernate能支持更复杂的映射功能或其他类似的东西而是在于——EF不仅仅是一个ORM它是在基于实体理念的数据平台中庞大愿景中的第一步
作为回应Frans BoumaLLBLGen 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的高级顾问也在他的博客中回应到
我认为把数据模型共享给你边界外的任何人是错误的（参看EvansDomainDriven Design）把概念模型或EDM或其它我们以任何名字称呼它的东西共享出来也是错误的
我从来不把域对象直接通过服务暴露出来这是对我尽量创建的封装的一种侵害
如果任何人想要一个SSRS【译者注SQL Server Reporting Service】那么我会给他们一个单独的报表数据库——为报表所需而定制的我不希望报表的关注点影响了我们的事务关注点一个映射层不能解决这样的问题但类似SSIS【译者注SQL Server Integration Service】这样的产品却可以你想要报表？好这里有你需要的只读视图每小时分钟每天或随时进行更新
所以现在的问题是ADONET实体框架是否已经不仅仅是一个O/R Mapper了以及它如何和nHibernate进行比较？很多人倾向于认为EF是一个简单的O/R Mapper并认为它相对于nHibernate而言缺乏很多特性另外一方面Danny Simmons说微软刚刚开始开发EF他们的计划是未来要超越当前的O/R映射功能
