对我来说，目前的答案是：不，我会使用 iBatis，因为当数据库模型和对象模型不同步时，NHibernate 很痛苦。如果我不能完全控制数据库，我最终会做很多工作。
我为什么要问？
好吧，首先：我从未使用过 NHibernate。我只是从表面上知道。我已经阅读过 iBatis 对遗留数据库的优势。
第二：最近我与使用 Hibernate 的人进行了讨论（jep，在 Hibernate 之前没有'N'）。他告诉我，ORM 框架现在非常先进，并且提倡 Hibernate。由于我对 NHibernate 不感兴趣，所以我没有跟踪最近的发展。
也许我是时候重新考虑我的答案了，或者不是？
iBatis 很容易将对象映射到遗留数据库系统。
最近 NHibernate 1.2 和 2.0 有一个特性集，可能会让你重新思考 iBatis。
NHibernate 与复合键一起工作，这在旧数据库中经常出现，它们并不总是令人愉快的工作，但对此提供支持。
NHibernate 可以利用存储过程对实体以及数据库视图进行 CRUD 操作。
集合可以是自定义存储过程或 SQL 查询。当外键关系不直接映射到另一端的主键时，集合可以使用 property-ref 属性。
其中一些特性可能会影响 nhibernate 的性能/功能，即使用 property-ref 的延迟加载不起作用（根本？），但大多数情况下都有原因。
其他要点：（这与您的旧数据库并不真正相关，但仍然可以帮助决定技术选择）
Nhibernate 社区似乎比 iBatis 丰富得多。我在这两个列表上，与 iBatis 组相比，对 NHibernate 的支持量相当大。所以支持应该更容易。
Also there is a growing amount of contrib/3rd party tools for NHibernate. Things like The NHibernate Profiler, the Nhibernate Query Analyzer, NHibernate Contrib, Fluent NHibernate to name a few.
Perhaps you can expand on what advantages you believe iBatis currently has. NHibernate has certainly been quite active recently and has gained many new features, a lot of which do assist in legacy/hard to modify schemas.
And to answer the question, yes we do use NHibernate with legacy databases that have awful relationships, composite keys, broken relationships. We still also have a small amount of code based on iBatis. We no longer write any more iBatis code though.
是的，考虑 NHibernate。这是黄金标准是有原因的。我听说 iBATIS 支持疯狂的映射可能性，但是使用 NHibernate 的 IUserType 你可以映射任何东西，甚至是非常奇怪的列。
@Ahmad，ORM 的全部目的是防止对象和模式之间的紧密耦合。如果你有这个问题，你做错了。
此外，使用 NHibernate 有很多用于自定义查询、公式属性和存储过程的选项。HQL 非常强大，Criteria 非常灵活。
我认为，如果您至少不使用 NHibernate，您将对您的客户造成伤害。
我一直在现有应用程序中使用 nHibernate。我将它用于所有新的开发，我无意将现有的东西移植到那里只是没有令人信服的理由，但对于项目中的新东西来说它工作得很好。
如果您要移植代码，那么您应该能够更改数据库以更好地与您的域模型匹配，而不会产生太大影响（取决于您的数据库的泄漏程度，即谁访问它）。但是，更改域模型会影响应用程序。