对于那些使用NHibernate和类似东西的人，为什么要使用它？对我来说，手动编写SQL似乎更容易。
答案 0 :(得分：8)
生产力和跨数据库可移植性是两个原因。 Hibernate / NHibernate或其他ORM允许人们轻松地将对象序列化到数据库或从数据库中序列化，而无需手动编写（和维护）大量SQL语句来完成这些操作。我不了解你，但为我们系统中的数百个对象编写和保存大量CRUD查询不是我的乐趣，也不是开发人员的时间！我不确定NHibernate是否有类似的机制，但Eclipse的Hibernate Synchronizer插件真的很棒：采用映射文件并自动生成对象和DAO。好东西！
性能（在L1和L2缓存中）是另一个原因 - 当然你当然可以写出骨干的findAll（）类型代码，这使得这一点没有实际意义，但总的来说，他们已经投入了大量的时间和精力，所以你需要更多的代码来重塑自己。
现在可以肯定的是，对于N / Hibernate来说，有一个非常重要的学习曲线，但是就像大多数事情一样，一旦你得到它，你会想知道没有它你是如何生活的。
那就是说，ORM不是一颗银弹（尽管它们非常好，一般而言）并且它们并不适合所有情况。我们仍然为复杂或高度优化的查询编写SQL。也就是说，我的团队的开发人员对Hibernate发誓，如果我们回到直接编写SQL的话，他们可能会反抗。
答案 1 :(得分：2)
This question可能会帮助你，已经有关于SO的a lot more ORM相关问题，主要涵盖NHibernate ，因为这是'人民的选择'以及Subsonic和Linq -to-SQL。
简而言之：
对于没有一对一和多对一的项目，或者复杂的查询，如果你是新手，它几乎没有任何好处。还有很多其他人通过不那么陡峭的学习曲线来做到这一点。
答案 2 :(得分：1)
使用迄今为止尚未提及的NHibernate的一个原因是使用NHibernate允许您使用Linq。大多数人都认为Linq很棒。
如果没有支持Linq的数据层并且通常需要ORM，则无法使用Linq。如果您打算使用ORM以便使用Linq，那么NHibernate是最佳选择。
手工编写SQL很好，但它通常比使用ORM要繁琐得多。当您可能要在数据库，数据层和业务层中复制某些“设计”时，为CRUD操作手写SQL是没有意义的。
一旦您决定不再编写另一组CRUD SQL，就会开始考虑ORM。一旦开始考虑ORM，您可能最终选择NHibernate作为最佳选择。
根据您的一些评论，您肯定也想考虑Fluent NHibernate，因此您不必处理手动编写XML配置文件。
答案 3 :(得分：0)
你的意思是什么？ 假设以下标准订单 - ＆gt;行项目 - ＆gt;产品设置。如果我想查找包含产品订单项的所有订单，我可以在HQL中编写： 从订单订单，LineItem lineItem，产品产品中选择订单 其中product.id =：id 和product.id = lineItem.product.id 和order.lineItems的lineItem成员
这样的SQL要麻烦得多。特别是如果你在混合中有多个数据透视表等。单独的“成员”短语的SQL代码是值得避免的。 所以SQL更容易设置，主要是。 SQL更容易编写吗？不适用于任何重要的对象模型。 那么，你的意思更容易了吗？
答案 4 :(得分：0)
虽然你的问题可能被解释为开始一场宗教战斗的诱因，但我会认为你老实好奇，并且想要理解为什么NHibernate在某些情况下可能有意义......
“更容易”是一个主观词。您的意思是说使用计划内嵌SQL创建应用程序所需的时间更短吗？这可能适用于您的应用程序。当然。根据我的经验，代码在很快之后仍然很脏。
你的意思是简单的内联SQL更容易阅读吗？我认为，随着应用程序复杂性的增加，您可能会发现读取SQL的行和行更加困难。分析结构良好的领域模型。
事实是，这取决于。开发人员不应该将自己嫁给一个工具。 NHibernate是一个工具。我认为NHibernate对于那些需要ORM的人来说是一个非常好的工具。但是当你真的需要内联sql时，它变得不那么有用了。
如果你正在制作一件T恤......你可能不需要锤子。
答案 5 :(得分：-1)
当然，我只会使用一种在时间系数上有一定成熟度的产品。 自2001年成立以来，nHibernate并未建立良好的商标。
不断变化。代码很难阅读和理解。没有视觉效果 设计师。整个过程似乎很难或无关。
我为医疗机构开发系统。所以我别无选择，只能依靠成熟的专业软件。
nHibernate不是由专业工程师设计的。