可持续性无知量表吗？

Question

我一直在看NHibernate和Linq2Sql。我也打算查看实体框架。

即得到提高，当我跟这些ORM的是“他们不能规模化”的问题，这样可以吧？从谷歌我得到他们能够很好地扩展的印象，但最终我认为必须付出代价，是否值得为更简单的业务层付费。

Answer 1

这是一个很好的问题，恕我直言，他们可以扩展一样好任何自定义DAL。我只使用nHibernate，所以我只关注它和它具有的可以帮助扩展系统的功能。

• 延迟加载 - 由于它支持延迟加载，因此您可以避免加载任何unnessecary项目。当然，您需要注意选择n + 1问题，但系统中有些东西可以防止这种情况发生。
• 渴望获取 - 有各种方法可以热切地获取您可能需要的对象，从而避免额外访问SQL。
• 二级高速缓存 - nHibernate支持二级高速缓存，可以通过减少到DB的行程来增加可伸缩性。有各种支持提供商可以提供一些灵活性。
• 编写您自己的SQL - 在nHibernate中，您可以调用存储过程，或者提供将返回实体的内联SQL查询。这将让你使用自己的SQL时，生成的SQL不会削减它。例如，使用递归查询加载自连接树。

现在有了这样的说法，我认为最初调整一个自定义DAL层比较容易，因为您的构造很亲密，可以对它进行微调;然而，一个好的ORM将提供大量的钩子，让你可以优化很多。你只需要花一些时间来学习它。

我也觉得，如果你有一个代码性能的关键领域，你不能让你的ORM您的要求范围内工作，那么你的应用程序，你可以自定义生成自己的DAL层的面积很小。如果您使用的是像样的设计模式，例如由工厂创建的Repository，那么您所需要做的就是替换您的存储库的实施。

Answer 2

Hibernate Shards正在ported to NHibernate，这将允许水平缩放。

也有一些非常酷的黑客喜欢this one实行分片。

因此，答案是肯定的，NHibernate的可以缩放，在持久性，无知和完全透明的方式。

Answer 3

这是不正确的说，ORM内置的应用程序不能很好地扩展。当然，它发生在那些粗心大意或懒惰的开发者通过编写生成可怕的低效SQL的代码来滥用ORM。构建高性能应用程序意味着理解有关所有可爱的抽象实际上在做什么。然而，避开这个陷阱并不需要太多。使用ORM并不意味着从不打开SQL分析器或NHibernate Profiler。

而关于SP快得多的说法，请阅读this和this。此外，ORM（NHibernate，至少）给你很容易的方式来使用SPs，如果你需要的话。