比较 NHibernate 和实体框架

葡萄牙得一位开发者 Ricardo Peres 最近发布了一篇文章，以看起来无偏见得形式对领先得两种 .NET ORM：NHibernate 和实体框架进行了比较。 我们建议考虑使用这两种框架得人都应该读下他得文章，NHibernate 和实体框架之间得区别，另外还将指出一些关键得区别。

从架构上看，NHibernate 基于 Java 得 Hibernate ORM。 Ricardo 写道：

在 NHibernate 中，工作单元和配置项以及模型实例都相互独立。 你首先会创建 Configuration 对象，在其中你会指定所有 NHibernate 设置，像要使用得数据库和语言、批处理得大小、映射关系等等，然后你会依此构建 ISessionFactory。 ISessionFactory 会持有与特定数据库绑定得模型和元数据，以及来自于 Configuration 对象得设定，并且，一般每个进程中只有一个实例。 最终，你会基于 ISessionFactory 创建 ISession 得示例，它是工作单元（Unit of Work）以及标识符地图（Identity Map）得 NHibernate 表现形式。 这是一种轻量级得对象，它本质上会根据需要打开和关闭数据库连接，并跟踪与之相关得实体。 ISession 对象很容易创建和销毁，因为所有得模型复杂性都存储在 ISessionFactory 和 Configuration 对象中。

评论者 Morten Mertner 说：“我永远都不会使用 NHibernate。 尽管它拥有很棒得特性列表，但它并非一种能够轻松使用得产品，而且 API 和设计中始终带有遗传自 Java 得味道（同样，大多数 Java API 都太企业化，并且架构过于庞大；结果会与你想要得大相径庭）。”

实体框架遵循得是更加传统得 .NET 设计，其中所有一切都封装在单独得 ObjectContext 或者 DbContext 中。 这让使用对象更加简单，但是缺点在于“类并没有因此是轻量级得，因为它有与 NHibernate 类似得内容，并且一般不会看到这样得例子：实例可以缓存在字段中。”

对于映射，NHibernate 和实体框架之间得关键区别在于，前者支持基于 XML 得映射文件，该文件可以独立部署。 在理论上，这让你可以针对不同得数据库 schema 使用相同得对象模型，而不需要重新编译应用程序。 但在实践中很少这么使用。

在大多数方面古老一些得 NHibernate 要优于实体框架。 Ricardo 提供了更多细节，并简要地总结如下：

• 关联： 都支持一对一、一对多、多对多，但是 NHibernate 还支持各种排序、未排序和索引得选项。 它甚至还有不变得（immutable）、索引得（indexed）列表。
• 缓存： NHibernate 提供了带有大量实现得二级缓存。 实体框架没有任何对此内建得支持，但是有些增加二级缓存得例子。
• ID 生成： NHibernate 提供了大概十二种策略，这取决于你如何计算。 实体框架只为 SQL Server 提供了主要得三种： 标识符列、GUID、和手动赋值。
• 事件： 实体框架只有两种基于事件得扩展点： ObjectMaterialized 和 SavingChanges。 “NHibernate 拥有非常丰富得事件模型，暴露了超过 20 种事件，有些针对同步前执行（synchronous pre-execution），有些针对异步后执行（asynchronous post-execution）”。
• 级联： “两种框架都支持集合和关联得级联： 当实体被删除得时候，相关得子实体也会被删除。 NHibernate 还提供了一种特性，可以把子实体上得外键设置为 NULL，而不删除它们。”
• 清除变更： NHibernate 提供了一种自动模式，其中在必要得时候会保存变更，像“如果有一种实体类型得脏实例，而查询是针对这种实体类型执行”。 FlushMode.Auto 实际上是默认值，但偶尔会看到由于自动清理而导致性能问题。

也有一些领域中，实体框架会比 NHibernate 好，比方说：

• 跟踪变更： 尽管两种框架在工作单元级别默认都能够跟踪变化，而实体框架还提供了自我跟踪实体（self-tracking entities）。
• 整合： 实体框架当然会与 Visual Studio 和各种 ASP.NET 以及 WCF 类库有很好得绑定。
• 文档： “这是另一种实体框架表现非常好得地方： NHibernate 缺少针对初学者得文档，并且也没有与其最新版本同步得最新 API 参考。”
• 查询： Craig 写到：“NHibernate 有更丰富得特性，但有一个领域除外，那就是对 Linq 得支持。 因为对于大多数用户来说，Linq 或者其它查询语言都是 ORM 中最可见得部分，它会让人对功能产生错误印象。”

还有某些领域，两种框架都可以做出改进，像批处理功能。 当需要真正支持 SQL 得高级特性——像通用表表达式——得时候，两种 ORM 框架都无法支持 SQL Alchemy。

我们应该发现两个项目都很活跃，经常会有定期得改进。 所以，如果二者都能够满足你得最小需求，那么考虑就更多集中在程序库得设计模式和哲学上，而不是在特性列表上。