很多人已经在网上讨论过Entity Framework的第一个版本（也在stackoverflow上），很明显，当我们已经拥有像NHibernate这样的更好的替代品时，它不是一个好的选择 . 但我找不到实体框架4和NHibernate的良好比较 . 我们可以说今天NHibernate是所有.NET ORM中的领导者，但是我们可以期待Entity Framework 4从这个位置取代NHibernate . 我认为如果微软真的在EF4中注入了非常好的功能，它可以给NHibernate带来很好的竞争，因为它具有Visual Studio集成，更易于使用，并且在大多数商店中总是优先考虑MS产品 .
10 回答
EF4在“自我跟踪实体”中有关于n层开发的开箱即用的答案 . 没人发布NHib的可比代码 .
NHib有很多未被提及作为EF4的一部分的功能 . 这些包括二级缓存集成 . 它还具有更大的继承映射灵活性，与存储过程/数据库函数/自定义SQL /触发器的更好集成，对公式属性的支持等 . IMO它作为ORM基本上更加成熟 .
Update: 我还没有在我的项目中使用NH或纯ADO .NET . 而且自从4.0以来我不再使用EF，因为NH完美无缺 .
当你使用两者时，实际上很容易比较它们 . EF4有一些严重的限制，我可以说出我自己遇到的一些问题：
EF4问题：
Eager Loading and shaping the result ：EF4 eager loading system（包含（"Path"））生成不正确的SQL，循环JOIN 's , which will execute thousands(not literally) time slower for many-to-many relationships then hand written SQL (it' s实际上无法使用） .
Materializer can't materialize associated entities ：如果您认为通过提供自己的SQL查询可以克服以前的问题，那就错了 . EF4无法从JOIN SQL查询中实现（映射）关联实体，它只能从一个表加载数据（所以如果你有Order.Product，SELECT * FROM命令LEFT JOIN产品将只初始化Order对象，Product将保持为null，认为在查询中获取所有必要的数据以初始化它） . 这可以通过使用EFExtensions社区附加组件来克服，但您必须为此编写的代码非常难看（我试过） .
Self-Tracking Entities ：许多人说自我跟踪实体对于N层开发来说很酷，包括这个帖子中的最佳答案 . 以为我没有简单地接受用户发送给你的更改并将它们应用到数据库，为什么不给用户直接数据库访问呢？你将不得不加载数据用户的任何方式即将从DB更改，检查它是否存在|不存在执行权限检查等等 . 你可以't trust user on the state of entity he is sending to server, you will anyway have to load this entity from DB and determine it'状态和其他东西，所以这些信息是无用的，自我跟踪也是如此实体，除非你做一个私人信任的n层系统供内部使用，在这种情况下，你可以只提供简单的数据库访问 . （多数民众赞成我关于ST实体和N轮胎的想法，我在N-Tier中没有经历过，所以它可以改变，如果我在这里误解了一些东西，请评论它）
Logging, Events, integrating business logic: EF4就像黑盒子一样，它有所作为，你不知道它做了什么 . 只有一个事件OnSavingChanges，您可以在DB发生某些事情之前放置一些您需要运行的业务逻辑，如果您需要在事情发生之前对业务对象应用一些更改，您将不得不深入了解ObjectStateManager，这真的很难看，代码可以变得巨大 . 例如，如果您使用Repository模式以及以干净对象方式对DB所做的更改通知的内容，那么您将很难使用EF进行此操作 .
Extensibility: 所有EF代码都是私有的和内部的，如果你确定它基于扩展方法's easer to write you own ORM from scratch (I did) then make EF work as you need. As example take a look at EFExtensions source, it'，并且不同的"hacks"使EF更加可用，并且代码非常丑陋（并且它不是作者的错误，当所有的东西都在EF是私有的，这是扩展它的唯一方法） .
我可以继续写关于EF的不好的事情，对我来说，用20页来处理它是多么痛苦，也许我会 .
What about NHibernate? 它比较像PHP和C＃，EF4就像Stone-age一样，它就像EF在开发过程中落后于NHibernate落后10年，实际上它是，Hibernate于2001年开始 . 如果你有空闲时间学习并打开Nhibernate，做到这一点 .
这就是事情 . 在我看来，NHibernate和Entity Framework真的适合两个不同的受众 . NHibernate将是我选择构建具有复杂映射，公式和约束的系统（基本上什么企业） . 如果我想通过简单的数据访问实现运行，我会使用Entity Framework或LINQ-to-SQL . NHibernate没有像EF那样清晰的“拖放”体验 . 两者都有其优点和缺点 . 坦率地说，比较他们苹果对苹果，无处可去 .
如果你认为你可能想要在Mono上运行你的代码，那么NHibernate可能是一个更好的选择，无论功能清单说什么...
Edit, 8/13/2012:
实体框架是开源的，自2.11.3起包含在Mono中 . 这个答案现在已经过时，不应该依赖 .
http://weblogs.asp.net/scottgu/archive/2012/07/19/entity-framework-and-open-source.aspx
我对此的看法是，自1.0以来EF4.0已经走了很长一段路，并且在功能上赶上了Nhibernate，但它还不是全部 .
然而，开箱即用的是微软，它完成了95％的应用程序需要它做的100％ . 然而，NHibernate多年来一直在做同样的事情 . 5.0版或6.0版可能会赶上，甚至超越NHibernate .
这是我的建议 - 如果你有时间学习两者，那就去做吧 . 选择一个而不是另一个有几个原因 . 如果您正在为公司编写代码，那么期望能够熟悉EF的员工是可行的，就像在所有书籍中以及孩子在大学里学到的东西一样 . 如果EF能够满足你的要求（在说出肯定之前想想这个很长很难），那么现在它是一个非常好的解决方案，并且在几年内它可能（好吧，很可能会）超越NHibernate .
NHibernate是一款非常成熟的产品，在EF上用了几年时间，很可能会做你想做的一切，然后做一些 . 它现在已经是最好的ORM，并且很多人都使用它 .
我认为EF 4能够使用POCO和延迟延迟加载的事实将非常大 . 我肯定能看到它在新版本中获得牵引力 .
与NHibernate相比，EF的受欢迎程度明显增加，见图 .
我的2美分：我们在桌面客户端上使用ef来获得一些cahing等 - 没有高负荷 . 服务器端的NHib - 利用无状态会话，hilo id生成和批处理 . 是以每秒db的速度插入3k消息是非常快的 . 它也非常灵活，支持大量的dbs，这对我们的产品至关重要 .
使用Linq组合逻辑层直接映射到存储过程似乎是最简单的方法 . 没有xml . 仅为不常使用或不适合存储过程的有趣查询生成sql .
对象通过标准SP加载和存储 . 这种方法允许使用两个sql登录 . 一个用于通过SP访问类（仅执行权限），另一个用于允许直接表访问的逻辑linq模块 .
在受欢迎程度的ORM之间进行选择并不是最好的选择 . 在过去的2年里，我试图转向EF，我只能说，为什么我还在尝试？
ATM我对EF的看法是：“它是为非常小的非常小的系统制造的，不超过3个表，关系少于1（0更好）” .
为什么我这么想？ 1.尝试更新断开连接的图表并查看模型划痕;
尝试使用深度继承的树创建TPH，您会发现您被绑定到单个层次结构或系统将中断 .
尝试进行更繁琐的查询，并观察整个系统消耗堆栈：D ...溢出经常发生 .
Map XML数据类型基于扩展或最“讨厌”的NotMapped属性......而且更糟糕 .
尝试将SQL查询混合到Linq以获取更多finner查询，然后您将破坏墙壁lol .
最后也是最重要的事情，EF不支持属性公式（'NH遗留数据库的一个很棒的资源'），并且不支持同一个表和相关表的复杂类型映射 .
那是我的10cc .