对我来说，目前的答案是：不，我会使用iBatis，因为当数据库模型和对象模型不同步时，NHibernate是一种痛苦。如果我没有完全控制数据库，那么我会做很多工作。您是否会将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的Lazy Loading不起作用（完全不？），但大多数情况下都有这样的原因。
其他几点：（这是不是真的与你的遗留数据库，但仍然可以帮助决定技术选择）
NHibernate的社区显得比iBatis的要丰富得多。我在两个列表中，与iBatis组相比，NHibernate的支持量相当大。所以支持应该更容易。
也有越来越多的NHibernate的contrib /第三方工具。诸如NHibernate Profiler，Nhibernate查询分析器，NHibernate Contrib，Fluent NHibernate等等。
也许你可以扩展你相信iBatis目前拥有的优势。 NHibernate最近确实很活跃，并且获得了许多新功能，其中很多功能可以帮助传统/难以修改模式。
并回答这个问题，是的，我们使用NHibernate与遗留数据库，有可怕的关系，复合键，断开关系。我们还有少量基于iBatis的代码。我们不再编写任何更多的iBatis代码。
如果您使用数据库通知，则缓存*可以*工作。 – 2009-01-22 15:35:08
我一直在现有的应用程序中使用nHibernate。我将它用于所有新的开发，我无意将现有的东西移植到那里，只是没有一个令人信服的理由，但是对于项目中的新东西来说，它工作的很好。
如果您要移植代码，那么您应该能够更改数据库以更好地与您的域模型匹配，而没有太大影响（取决于数据库的泄漏程度，即谁访问它）。但是，更改域模型会影响应用程序。
这不是一个代码端口。旧应用程序的许多部分仍然存在，应添加功能。数据库结构部分超出了我的控制范围（因为应用程序的旧部分以及其他现有部分的依赖关系）。 – 2009-01-18 11:50:45
是的，考虑NHibernate。这是有原因的黄金标准。我听说iBATIS支持疯狂的映射可能性，但对于NHibernate的IUserType，你可以映射任何东西，甚至是非常奇怪的列。
@Ahmad，ORM的整个目标是防止你的对象和你的模式之间的紧密耦合。如果你有这个问题，你做错了。
此外，与NHibernate有很多自定义查询，公式属性和存储过程的选项。 HQL功能非常强大，Criteria十分灵活。
我认为如果你至少没有加入NHibernate，你会为你的客户造成不良影响。
表格之间真正疯狂的连接如何？因为它部分是遗留数据库，所以还需要一些手动的SQL语句。 – 2009-01-20 00:22:54
这将是我的下一个问题在stackoverflow - 感谢问！ – SRO 2009-01-17 23:15:09