对我来说，目前的答案是：不，我会使用iBatis，因为当数据库模型和对象模型不同步时，NHibernate很痛苦。如果我没有完全控制数据库，我最终会做很多工作。
我为什么要问？
嗯，首先：我从未使用过NHibernate。我只是从表面上知道它。我已经了解了iBatis对旧数据库的优势。
第二：最近我与一个使用Hibernate的人进行了讨论（jep，在Hibernate之前没有'N'）。他告诉我，ORM框架现在非常先进并且提倡Hibernate。由于我对NHibernate不感兴趣，所以我没有跟踪最近的发展。
也许我有时间重新考虑我的答案？
答案 0 :(得分：5)
iBatis很容易将对象映射到旧数据库系统。
最近NHibernate 1.2和2.0的功能集可能会让你重新思考iBatis。
NHibernate使用复合键，它们可以在较旧的数据库中频繁出现，它们并不总是令人愉快，但对此有支持。
NHibernate可以利用存储过程对实体进行CRUD操作，也可以使用数据库视图。
集合可以是自定义存储过程或SQL查询。当外键关系不直接映射到另一侧的主键时，集合可以使用property-ref属性。
其中一些功能可能会损害nhibernate的性能/功能，即lazy Loading with property-ref不起作用（根本没有？），但大多数情况下都有原因。
其他要点:(与您的旧数据库无关，但仍可帮助确定技术选择）
Nhibernate社区似乎比iBatis更丰富。我在两个列表上，与iBatis组相比，NHibernate的支持量非常大。所以支持应该更容易。
此外，NHibernate还有越来越多的contrib / 3rd party工具。像NHibernate Profiler，Nhibernate查询分析器，NHibernate Contrib，Fluent NHibernate等等。
也许您可以扩展您认为iBatis目前拥有的优势。 NHibernate最近一直非常活跃，并且已经获得了许多新功能，其中很多功能都有助于遗留/难以修改模式。
回答这个问题，是的，我们确实将NHibernate与遗留数据库结合使用，遗留数据库具有糟糕的关系，复合键，破坏的关系。我们还有一些基于iBatis的代码。我们不再编写任何iBatis代码了。
答案 1 :(得分：1)
是的，考虑一下NHibernate。出于某种原因，这是黄金标准。我听说iBATIS支持疯狂的映射可能性，但是使用NHibernate的IUserType，你可以映射任何东西，甚至是非常奇怪的列。
@Ahmad，ORM的全部目的是防止对象和架构之间的紧密耦合。如果你遇到这个问题，你就错了。
此外，NHibernate提供了大量自定义查询，公式属性和存储过程的选项。 HQL非常强大，Criteria非常灵活。
如果你不至少加剧NHibernate，我认为你会伤害你的客户。
答案 2 :(得分：0)
我一直在现有的应用程序中使用nHibernate。我将它用于所有新的开发，我无意将现有的东西移植到其中，只是没有令人信服的理由，但对于项目中的新东西，它工作得很好。
如果您要将代码移植到那时，您应该能够更改数据库以更好地与您的域模型匹配，而不会产生太大影响（取决于您的数据库是如何泄漏的，即谁访问它）。但是，更改域模型会影响应用程序。