我知道NHibernate非常适合那些从头开始创建新数据库和构建项目的项目。但是，以我的经验来看，企业应用程序通常不是这种情况。通常情况下，整合来自其他数据库的遗留数据是新应用的重要组成部分。NHibernate for Enterprise应用程序？
当你打算处理无法控制的遗留数据库结构时，NHibernate是否会比作为ORM值得的更麻烦？
我知道构建数据服务和松散耦合的参数，并且会及时到来。但是，现在，如果我不得不使用来自两个不同现有数据库的15个表中的数据，除了存储我自己的应用程序数据外，正在使用NHibernate（或更广泛地说，任何类型的模型驱动的ORM工具）让我疯狂？
使用像NHibernate这样的ORM的主要优点之一就是它可以将应用程序的业务对象从数据库中分离出来。客户表是否包含地址信息，但您希望Customer对象包含地址类？ NHibernate可以在XML中快速轻松地完成这项工作。
使用ORM的一个要点是，您可以自由设计系统中的对象而不用担心数据库问题，然后将这些对象的属性映射到数据库中的表示形式。所以你可以遵循一个对象驱动设计而不是数据驱动设计方法。
ORMs被设计用于遗留数据库。他们可能有其缺点，但根据我的经验，这是非常有利的。
默认情况下，NHibernate会话配置为连接到单个数据库。可以将您的数据访问层设置为使用不同的NHibernate会话连接到不同的数据库。但是，如果您希望它自动将两个数据库之间的数据网格化为单个对象，那么您可能会感到失望。好的是NHibernate可以很好地处理数据库视图，所以如果你需要做一些复杂的事情，你总是可以编写一个可以通过数据库触发器更新的视图。就数据库设计而言，NHibernate具有各种各样的结构以允许传统数据库正常工作，如多列主键和其他“坏设计”怪异特性。
我会推荐它。
是的，视图通常可以很好地工作，因为大部分遗留数据都是只读的。 – ProKiner 2009-11-19 18:58:32
这只取决于你对NHibernate的适应程度。
虽然舒适度肯定会影响决策，但它也会损害某人远离更好的方法。只要有正确的动机，我可以对任何事情都感到满意，但我希望选择基于更长期的事情。 – ProKiner 2009-11-19 18:57:35
IT依赖， 我在这里也有一些问题，但仍然没有得到很好的答案。 你应该关心的事情：
a。使用NH与分层的应用程序可能会杀死NH会话的特殊功能 - 例如延迟加载。 WCF无法通过“半初始化”
b。如果没有良好的通知基础设施，会话缓存可能无用，而客户端不可用。
c。你需要学习HQL ....
有时ORM比自己做这项工作慢得多/效率低。
所以我想你需要在小规模项目上测试一下，看看它对你有什么价值，而不仅仅是在企业项目中试用它。
从性能的角度来看，你可以得到更好的性能做你自己....
Here是我自己关于这个问题的问题...没有很好的答案还在后头......
我认为这取决于您需要如何处理遗留数据库。
它只是为了阅读吗？我会手写一些数据访问代码，而不是处理多个会话工厂。但是，也许你需要创建复杂的动态查询，那么它可能是值得的麻烦。
+1这正是我目前在做的工作。 – 2009-11-19 18:11:34
传统数据已经很好地标准化了，所以抽象这种信息并不是主要关心的问题。我更关心的是试图扩展ORM以覆盖多个数据源。最后，在* my *数据库中创建一堆关注遗留数据的视图似乎是完成它的最简单方法。 – ProKiner 2009-11-20 14:41:05