持久性无知规模？

Question

我一直在简要介绍一下NHibernate和Linq2Sql。我也打算看一下实体框架。

当我谈到这些ORM时，提出的问题是“它们无法扩展”，它们也可以吗？从Google我得到的印象是他们能够很好地扩展，但最终我认为必须付出代价，是否值得为更简单的业务层付费。

Answer 1

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

• 延迟加载 - 由于它支持延迟加载，因此您可以避免加载任何不必要的项目。当然，您需要注意Select n + 1问题，但是系统中有些东西可以防止这种情况发生。
• 渴望获取 - 有多种方法可以急切地获取您可能需要的对象，从而避免额外的SQL访问。
• 二级缓存 - nHibernate支持二级缓存，可通过减少数据库访问来提高可扩展性。有各种支持提供商可以提供一些灵活性。
• 编写自己的SQL - 在nHibernate中，您可以调用存储过程，或提供将返回实体的内联SQL查询。当生成的sql没有删除它时，这将允许您使用自己的SQL。例如，使用递归查询急切加载自联接树。

现在有了这个说法，我认为最初调整自定义DAL层更容易，因为它与它的构造密切相关并可以微调它;但是，一个好的ORM会提供大量的钩子，让你可以优化很多。你只需花一些时间学习它。

我还认为，如果您有一个性能关键的代码区域，并且无法让ORM在您的要求范围内工作，那么对于应用程序的这个小区域，您可以自定义构建自己的DAL层。如果您正在使用一个像样的设计模式，例如工厂创建的存储库，那么您需要做的就是更换存储库的实现

Answer 2

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

还有一些非常酷的黑客如this one来实现分片。

所以答案是肯定的，NHibernate可以用持久无知且完全透明的方式进行扩展。

Answer 3

说在ORM中构建的应用程序不能很好地扩展，这是完全错误的。当然，在此之前，粗心或懒惰的开发人员通过编写生成非常低效的SQL的代码来滥用ORM。构建高性能应用程序意味着了解所有可爱的抽象实际上做什么的内容。但是，避开这个陷阱并不需要太多。使用ORM并不意味着永远不会打开SQL分析器或NHibernate Profiler。

关于SP的速度要快得多，请阅读this和this。此外，ORM（至少NHibernate）为您提供了非常简单的方法来使用SP。