NHibernate 或 FluentNHibernate 或 ActiveRecord？

Question

我正处于将我的 CSharp 类映射到数据库表的阶段。在与其他工具比较之后，我决定使用 NHibernate 作为我的 ORM 工具。我以前从未用 NHibernate 做过真正的项目，现在正在考虑映射的替代方案，

ActiveRecord：根据该项目的网站，使用 ActiveRecord 可以显着提高生产力。但是，我不喜欢向我的 CSharp 类添加属性的想法。毕竟，我的班级不应该对数据库关系有任何了解。通过使用 ActiveRecord 会将我很好分离的类绑定到 ActiveRecord，如果我以后想要切换下划线 DAO 层实现，我会很难过。

FluentNHibernate：FluentNhibernate 是我开始映射时的第一次尝试。但我对这种方法也有一些问题。 1) 我不喜欢将映射策略编译为二进制文件。我希望能够通过修改 xml 文件来更改映射。 2) FluentNHibernate 的成熟度。 NHibernate 已经存在了很长时间，并且拥有大量的用户，所以我对它的成熟度很满意。相比之下，FluentNhibernate 相对年轻，没有经过那么多用户的测试。尽管我可以深入研究源代码来解决出现的任何问题，但我对自己接触低级实现的技能感到不舒服。 3) FluentNHibernate 的文档可用性比 NHibernate 的多。碰到硬墙的时候想有个地方去。

NHibernate：目前，我正在使用裸 Nhibernate xml 进行映射。老实说，使用 XML 让我非常头疼。从字面上看，我必须让自己远离仅仅扔掉 .hbm.xml 文件并每天多次抓取 ActiveRecord 或 FluentNHibernate 的冲动。

所以，这是我的两难选择：我是否应该带着“把这该死的事情做完！”的心去做；或者，我应该遵循“良好实践指南”来忍受现在的痛苦，以后过上相对轻松的时间吗？

有没有cmets？

Answer 1

请注意，与 ORM 相关的任何类都不应被视为“业务对象”类或暴露给您的 UI。它们应该被视为数据层的一部分。这种模式并不是 ActiveRecord 真正独有的。通常，您希望您的业务层尽可能少地了解它下面有一个 ORM 的事实，并且您不希望您的 UI 知道您的数据层。你也可以考虑DTOs。

Fluent NHibernate 解决了弱类型 XML 的问题，这种弱类型的 XML 易于重构。

虽然采用 ActiveRecord 之类的方法可能存在缺点，但在您的情况下这似乎是一个合适的解决方案。

使用 .hbm.xml 文件的最佳理由是，如果您要使用代码从数据库中生成它们（使用类似 CodeSmith 的东西）。手动编码 .hbm.xml 文件很少是最佳选择。