我在使用nHibernate和手写的ado.net/存储过程之间来回走动。
我目前使用的代码匠使用我编写的模板，这些模板用于映射我的数据库表的简单类，它包装了我的数据层的存储过程，以及一个只调用我的数据层并返回对象的瘦业务逻辑层（ 1个对象或集合）。
此应用程序是一个Web应用程序，用于在线社区（基本上是一个论坛）。
我现在正在观看夏天的nhibernate视频。
使用nHibernate会让我的生活更轻松吗？是否可以更轻松地更新数据库模式？性能会有什么影响？
设置nhibernate，并确保它最佳地执行自己的头痛？
我不想要复杂或深层的对象模型，我只想要映射我的表的类，以及从其他具有外键的表中获取数据的方法。我不想要一个非常复杂的OOP模型。
答案 0 :(得分：4)
NHibernate绝对可以让您的生活更轻松。对数据库模式的更新肯定会更容易，因为当您使用ORM时，您没有存储过程的API，这会阻碍您重构数据库模式以满足业务模型的更改。
OR mappers有很多东西可以提供，很遗憾被开发者社区的很大一部分以及几乎所有的DBA社区误解。
存储过程通常为DBA提供了更多选项来调整数据库中的性能，因为只要它们不更改其输出，它们就可以自由地重写存储过程。但是，根据我的经验，存储过程很少被重写，因为可能会出现其他问题（即，当执行新版本软件的部署时，现有过程的任何修改版本都将覆盖已更改的优化版本由DBA ......因此否定了利益并产生了维护和意外的性能问题。）
另一个严重的误解（这主要来自SQL Server阵营......我对Oracle的经验很少），是存储过程是唯一可以编译并缓存执行计划的东西。就SQL Server而言，任何参数化查询都可以编译和缓存。
OR映射器的一个好处是它们是自适应的......使用存储过程，您可以编写一个语句，在执行该查询时，无论上下文细微差别如何，都将使用该语句。 LINQ to SQL具有惊人的能力来生成我见过的最有效的查询，并且经常抛出DBA的严重循环。我已经展示了由L2S生成的DBA查询，这些查询充满了子查询和非传统的东西，这些东西立刻被嘲笑。然而，考虑到挑战，由DBA编写的查询的性能（即物理读取）被认为是优越的，结果明显较差（有时在L2S的30个物理读取和DBA的400个物理读取的规模上。）< / p>
就DBA而言，另一个令人沮丧的是，因为ORM生成动态SQL，所以他们无法优化这些查询。相反（同样，这仅限于SQL Server），SQL Server提供了大量优化路径（水平和垂直表分区，在任何表或视图的磁盘上分配物理文件，索引等），在需要修改查询之前采取是必要的。即使在需要修改查询的情况下，SQL Server 2005及更高版本也提供了一个名为Plan Guides的东西，它允许您适度调整任何查询（存储过程，strait sql等）。如果调优查询不够，您可以将任何特定查询与完整的替换查询匹配，从而允许DBA根据需要调整查询（但作为最后的手段。）
使用OR映射器可以获得很多很多好处，而NHibernate是最好的免费之一（LLBLGen也非常好，但不是免费的。）LINQ to Sql和Entity Framework是一些新的来自Microsoft的产品（很快就会被来自.NET 4.0框架的EF 4.0取代......至少可以与NHibernate相提并论。）采用ORM的最大障碍通常不是ORM产品本身，它的能力或表现。最大的障碍通常是说服你的DBA（如果你的幸运/不幸......取决于你的经验......有一个），ORM可以提高效率并降低维护成本，而不需要DBA的优化路径成本。 / p>
答案 1 :(得分：2)
NHibernate工作得很好，特别是对于一个简单的模型。它会让你的生活更轻松，也不会太难学。看看“Fluent NHibernate”而不是使用XML映射，它更容易。