NHibernate O / R问题

Question

多年来我写了很多ejb，oledb和ADO代码。我对O / R地图制作者的体验充其量只是为了提高速度，最糟糕的是充满了噩梦。

NHibernate或Spring .NET是值得的，为什么？

Answer 1

我没有使用Spring.Net数据模块，所以我不会对此发表评论。 我使用Spring.Net作为它的IOC。总的来说，我认为你可以做得更好。

NHibernate非常好。它比ADO.Net要慢，但总的来说，还不足以让你担心。关键是NHibernate允许您快速启动和运行数据库代码，因此您可以担心实际的应用程序代码。您的应用程序不仅仅是数据库。

然后，当您发现需要很长时间且影响应用程序性能的查询时，请使用传统方法重写THAT方法。

还有其他替代方案，实体框架，SubSonic，LLBLGen等。

Answer 2

正如Matt所说，ORM对于分离他们在应用程序设计中允许的问题很有价值。当然，最重要的权衡是原始表现。我认为，您可以随时扩展硬件资源，但不能轻松扩展和扩展紧密耦合的代码。

如果您正在查看.net空间，请考虑Lightspeed。它是一个商业ORM，但速度明显快于NHibernate，并且通常更直观。

Answer 3

它们值得“麻烦”，因为它们可以让您在与行为和其他代码分离的模型中清楚地定义数据。您不需要编写自定义DAL。他们帮助分离关注点。

Answer 4

这取决于你的焦点，我想。

在我的店里，有些人喜欢他们（真正的Java / OO螺旋桨头），有些人鄙视他们（有更多的SQL技能）。

我是第二组，但我是开发人员DBA。

它们本身并不是邪恶的，但如果在没有任何宗教包袱的情况下正确使用，它们只是一个有用的工具。

Answer 5

如果您不介意与SQL Server的紧密耦合以及与架构的相对紧密耦合，您可以考虑查看LINQ to SQL。它是框架的一部分，非常简单，并且非常容易编程。使用VS 2008附带的设计器，您可以在几分钟内启动并运行编码。

也就是说，LINQ to SQL并不是最终的全部; NHibernate在很多方面肯定更强大，并且还有整个Entity Framework迁移。

但LINQ to SQL并不是速度的承受力。我可以从经验中告诉你，尽管设计师并非完全没有错误，但它非常强大，而且潜在的基础知识至少不会错误。

LINQ to SQL实际上是一个功能强大且成熟的ORM。

如果您需要一个LINQ to SQL强大功能的实例，请查看此网站。它使用LINQ to SQL作为后端，我认为它根本不慢。

Answer 6

NHibernate绝对值得付出努力。正如其他人所说，它比直接使用ADO.Net等慢，但我认为生产力的提高是值得的。在性能方面，你可以在NHibernate中做一些调整来加快速度：

1. 延迟加载 - 仅在实际请求时从数据库加载子对象/集合
2. 缓存 - NHibernate具有一级和二级缓存。默认情况下使用第一级缓存，这意味着NHibernate不会在同一会话中多次运行相同的查询。二级缓存由用户决定，您可以在其中选择哪些操作可缓存（由第三方缓存引擎），NHibernate将为您处理。例如。如果您多次加载一个对象（跨所有会话），并且该对象很少更改，使其可以缓存以加快速度。