NHibernate 还是流畅的 NHibernate？ [关闭]答案

【问题标题】：NHibernate or Fluent NHibernate? [closed]NHibernate 还是流畅的 NHibernate？ [关闭]
【发布时间】：2010-11-23 23:13:54
【问题描述】：

我很想听听其他人关于他们是否会选择哪一个（请不要“两者都选”；）以及为什么选择的意见。

使用 fluent 有什么缺点？（版本依赖可能？）优点、缺点、经验等。

【问题讨论】：

hbm.xml 文件在 NHibernate 中用于映射，但 Fluent NHibernate 在 C# 代码中替换了它。很容易发现问题和维护。
我在 3 年前问过这个问题，这个月就关门了？嗯。

标签： nhibernate orm fluent-nhibernate alt.net

【解决方案1】：

Fluent NHIbernate 位于 NHibernate 之上，因此它并不是两者之间的真正选择。如果您打算使用 NHibernate，请选择在其之上使用 Fluent NH，以节省大量精力。

Fluent NHibernate 很棒，没有它我不会使用 NHibernate。您可以流畅地映射所有实体（为您提供编译时间检查和自动化测试支持），而不必维护繁琐的 xml 文件并记住它们的语法/DTD。

它还可以根据默认和/或您自己的自定义约定自动映射您的实体。

随便用吧！

【讨论】：

是的，抱歉，我的问题应该稍有不同；）感谢您的回答。
是的，我完全同意。我们将 Fluent 与 Rhino 和 Geo 库一起使用。我们偶尔会遇到版本差异！
我同意这一点。我刚开始使用 Fluent NHibernate，我不会（不会）回头看。映射您的类是多么容易，这真是令人惊讶。
是真的吗，不支持流利的了？
@Johnny_D 它还没有死，但是自从 Mapping by Code 进入操场以来，开发速度大大放缓。

【解决方案2】：

我肯定会说使用 fluent-nhibernate。请注意，它可能不一定像您希望的那样顺利。

关于版本依赖
1. 当升级到新版本的 FNH 时，我遇到了一个“反向”依赖问题，需要我升级到新版本的 NH（我认为是 2.0 到 2.1）。这对我来说不是什么大问题。
2. 我最近（今天早上）将 NH 2.1.1 放入 FNH 1.0 RTM（这是随 2.1.0 分发的），没有任何戏剧（还）。
编辑：自从写这篇文章以来，FNH 已经成熟到我认为这不再是一个真正的问题的地步了 映射支持 - 流畅的 nhibernate 尚无法实现某些映射。但是，这不是避免 FNH 的理由，因为混合 fluent-xml 映射允许您在 fluent 无法映射它的情况下回退到传统 xml（尽管这仅适用于每个类的粒度）。映射示例：
1. 还不能映射字段 - http://groups.google.com/group/fluent-nhibernate/browse_thread/thread/a7787927dafd23a/84ce2616946a18d7
2. 无法映射字典 http://groups.google.com/group/fluent-nhibernate/browse_thread/thread/d38b6c72250cd2fb 的某些时间 - 实际上，据我所知，此功能存在，但尚未在主线中。
复合复杂度系数。从它的声音来看，您将同时学习 FNH 和 NH。对于大多数相当简单的应用程序来说，这很好——事实上，FNH 通常非常好，以至于您几乎不需要了解 hbm.xml 映射。但是如果你想做一些相当复杂的事情，它很少会在第一轮工作，你会想知道它是 PEBKAC、流利还是 NH 问题。比我希望的更多的时候，我最终编写了传统的 xml 映射（当然，无论如何你都在这样做，但最好不要花费更多的精力而不是首先摆弄 fluent）。
李>

【讨论】：

感谢您的想法 - 我在第 3 点听到您的意见。最后我选择了 FNH，但我也在做一个不流畅的小项目 - 这是一个非常好的主意，因为我感觉我学到了很多关于 NH 的知识，并且真正知道发生了什么感觉更舒服。（顺便说一句，我不得不查找 PEBKAC，但是是的 - 这是我的大部分问题的根源；）
仅供参考，最新版本现在支持字段。
您始终可以从流利的映射中生成 hbm.xml 并手动编辑它们。无需全部手写
我要补充一点，使用 Fluent 配置和 PersistenceSpecification 可以轻松地对映射进行单元测试
Fluent 仍然不允许使用自定义参数化类型映射属性。在尝试解决 nhibernate.jira.com/browse/NH-2528 的后果时遇到了问题

【解决方案3】：

将 Fluent NHibernate 与 NHibernate 一起使用的优点是，如果您弄乱了映射，您会得到编译时错误，而不是运行时错误。在重构代码时，您还可以获得更好的体验，因为您的映射会在您重命名属性或其他任何内容时保持最新，而不必记住手动修改 XML 映射文件。

Fluent NHibernate 最大的缺点是它仍处于开发的早期阶段，随着框架的开发进展，存在相当大的破坏更改的风险。

【讨论】：

根据我的经验，我在使用 FluentNHibernate 时遇到的由于映射错误导致的大多数错误发生在运行时，即 NHibernate 首次在应用程序中使用时。只有简单的重构/类型不匹配/拼写错误/等。会导致编译时错误。

【解决方案4】：

就我个人而言，我对流利的 nhibernate 并没有真正了解，因为我对映射文件感到满意。使用 Visual Studio 创建映射文件轻而易举，您可以为 xml 文件设置架构，从而为您提供映射文件的智能感知。我同意编译时语法检查是使用 fluent-nhibernate 的一个优势，但是当我已经熟悉 XML 映射时，我很难证明学习 fluent API 的合理性。也许我应该克服我的嗜睡并已经学习它...... :-)

【讨论】：

【解决方案5】：

Fluent N-Hibernate 确实是 NHibernate 的一个很好的包装器。在 Fluent 中管理映射比 xml 映射好得多。使用 Fluent 后，开发变得更快......

最好使用 Entity Developer 创建实体和数据库架构。

【讨论】：