实体框架4与NHibernate
很多人已经在网络上讨论过Entity Framework的第一个版本（也是在stackoverflow上），很明显，当我们已经有了像NHibernate这样更好的选择时，这不是一个好的选择。 但我找不到实体框架4和NHibernate的比较。 我们可以说今天NHibernate是所有.NET ORM中的领导者，但我们可以期望Entity Framework 4从这个位置取代NHibernate。 我认为，如果微软真的在EF4中注入了非常好的功能，它可以给NHibernate带来很好的竞争力，因为它具有Visual Studio集成功能，更易于使用，并且在大多数商店中始终给予MS产品优先选择权。
在“自我跟踪实体”中，EF4对于n级开发提供了一个开箱即用的答案。 没有人发布可比的NHib代码。
NHib有很多功能，这些功能都没有被提及为EF4的一部分。 这些包括二级缓存集成。 它在继承映射方面具有更大的灵活性，与存储过程/数据库函数/自定义SQL /触发器的更好集成，对公式属性的支持等等。 IMO基本上只是作为ORM更成熟。
更新：自4.0版本以来，我还没有使用实体框架，所以我的答案可能已过时。 我仍然在我的项目中使用NH或纯ADO .NET。 自从4.0以来，我甚至不想看看EF的新功能，因为NH完美地工作。
事实上，当你使用两者时，很容易比较它们。 EF4有一些严重的限制，我可以列举一些我自己遇到的情况：
EF4问题：
自我追踪实体 ：许多人认为自我追踪实体对于N层开发很酷，包括本主题中的最佳答案。 以为我甚至没有给他们一个尝试，我可以说他们不是。每个输入都可以伪造，你不能简单地将用户发送给你的改变应用到数据库，为什么不给用户直接数据基地访问呢？ 任何你将不得不加载数据的用户都将从数据库中进行更改，检查它是否存在|不存在执行权限检查等等。你无法相信用户对他发送给服务器的实体的状态，反正必须从数据库加载这个实体并确定它的状态和其他事情，因此这些信息是无用的，自我跟踪实体也是如此，除非您为内部使用建立私有的可信的n层系统，在这种情况下，您可能只是简单地数据库访问。 （这是我关于ST实体和N轮胎的想法，我在N-Tier中并没有很好的体验，所以如果我误解了某些内容，它会发生变化）
记录，事件，整合业务逻辑： EF4就像黑匣子，它做了一些事情，你不知道它做了什么。 只有一个事件OnSavingChanges，您可以在DB发生某些事情之前放置一些您需要运行的业务逻辑，并且如果您在发生某些事情之前需要对业务对象进行一些更改，则必须在ObjectStateManager中进行挖掘，这真的很难看，代码可能会变得巨大。 例如，如果您使用Repository模式以及以干净对象方式对DB进行的更改进行通知，您将很难用EF做这件事。
可扩展性：所有EF代码都是私有的和内部的，如果你不喜欢某些东西（如果你认真对待EF使用，你不会喜欢很多），但是你不能以简单的方式改变它，事实上我确信从头开始编写自己的ORM（我确实）很容易，然后根据需要让EF工作。 举例来看EFExtensions源代码，它基于扩展方法，以及不同的“黑客”来使EF更有用，代码非常难看（而且这不是作者的错误，当EF中的所有内容都是私有的，这是唯一的方式来扩展它）。
我可以继续写关于EF的不好的东西，以及我为它工作20页的痛苦，也许我会。
那NHibernate呢？ 它是完全不同的级别，就像比较PHP和C＃，EF4就像石器时代一样，就像EF在开发过程中比NHibernate落后了10年，事实上，Hibernate是在2001年开始的。如果你有空闲时间要学习并打开Nhibernate，请执行此操作。
这是事情。 在我看来，NHibernate和实体框架真的适用于两种不同的受众。 NHibernate将是我构建一个具有复杂映射，公式和约束的系统（基本上任何企业）的选择。 如果我想通过简单的数据访问来运行，我会使用实体框架或LINQ-to-SQL。 与EF相比，NHibernate没有明确的“拖放”体验。 两者都有其优点和缺点。 坦率地说，比较他们的苹果，苹果，让你无处可去。
链接地址: http://www.djcxy.com/p/20317.html