作者 Abel Avram译者 朱永光 发布于 2008年6月9日 上午3时22分
博客帖子。在和传统的ADO.NET及LINQ to SQL比较之后，Danny又把实体框架和nHibernate进行比较，这就引起了其他开发人员的反对。下面是Danny的帖子的摘录：
帖子中写到：
我不同意这种说法：一个像Danny Simmons这样工作于实体框架中如此久的人，这样的人怎么能忽略这样一个事实——任何O/R Mapper都是针对实体理念的。在他最后一句话中所描述的东西，实际上是一个单一目的的O/R Mapper：就是让开发人员能在OO语言中使用实体实例，并把这些实例保存到如关系数据库这样的非OO环境中，反之亦然。假如所有的东西就是抽象的实体模型和它的投射，那么更大的愿景是什么呢？也许工具？它让开发人员创建这些投射和在应用程序代码中调用O/R Mapper服务根据容易。
博客中说到Danny Simmons：
他在比较NHibernate和实体框架过程中遗漏了一个重要的事实。实体框架对你的应用程序具有很强的入侵性，而Nhibernate没有。NHibernate让我能使用POCO的方式来对业务过程进行建模而无需知晓数据库。而，实体框架却要我把EF的基础结构直接加入到我的业务对象中。
博客上对其进行了评论
一个单一的模型不可能适应你的应用程序里包括事务行为、搜索和报表在内的所有方面……可以举出很多这样的内容来。如果你基于你的事务模型来创建报表，那么你就会遇到麻烦！
博客中回应到：
我认为把数据模型共享给你边界外的任何人，是错误的（参看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映射功能。