什么时候应该避免使用NHibernate的延迟加载功能?

从数据库中加载对象时,有明显的性能权衡。

如果您使用“热切加载”,那么您可以在单个查询中吸收大量数据,然后可以缓存这些数据。这在应用程序启动时最常见。您正在为数据库往返交换内存消耗。

如果使用延迟加载,则在单个查询中只会吸收最少的数据量,但每当需要与初始数据相关的更多信息时,就需要对数据库进行更多的查询,而数据库性能命中通常是大多数应用程序的主要性能瓶颈。

因此,一般来说,您总是希望准确地检索整个系统所需的数据。” unit of work “,不多,不少。在某些情况下,您可能不确切知道您需要什么(因为用户正在通过向导或类似的东西工作),在这种情况下,在您进行加载时进行延迟可能是有意义的。

如果您使用的是ORM,并且专注于快速添加功能,稍后还会回来优化性能(这是非常常见的,也是一种很好的方法),那么将延迟加载作为默认值是正确的方法。如果您稍后发现(通过性能分析/分析)您有一个查询来获取对象,然后有n个查询来获取与原始对象相关的n个对象,那么您可以将该代码更改为使用“热切加载”只命中数据库一次,而不是n+1次(n+1问题是使用“延迟加载”的一个众所周知的缺点)。

对于懒惰的加载,通常的折衷方法是预先对数据库进行较小的访问,但最终长期对数据库进行更多的访问。 如果不延迟加载,您将在前面抓取一个完整的对象图,一次吞下一大块数据。这可能会导致用户界面延迟,因此通常不鼓励这样做。但是,如果您有一个公共对象图(不仅仅是单个对象——否则就不重要了!)你知道的东西会经常被访问,从上到下,然后立刻把它拉下来是有意义的。

例如,如果您正在执行订单管理系统,则可能不会在摘要屏幕上下拉每个订单的所有行或所有客户信息。延迟加载可以防止这种情况发生。

我想不出一个不直接使用它的好例子,但是我确信在某些情况下,为了避免处理过程中的延迟,您可能需要对对象图进行大量加载,比如在应用程序初始化时。

简短版本如下:

1. 如果使用延迟加载,则开发更简单。您只需以一种自然的OO方式遍历对象关系,当您请求它时,您就得到了您需要的东西。
2. 如果您在请求之前弄清楚需要什么,并在一次数据库访问中请求它,那么性能通常会更好。

在过去的几年里,我们一直专注于快速发展时期。现在我们有了一个可靠的应用程序和用户库,我们正在优化我们的数据访问。

如果在客户端和服务器之间使用WebService,使用nhibernate处理数据库访问,则使用延迟加载可能会有问题,因为将通过WebService序列化和发送对象,并且在对象关系中进一步使用“objects”需要使用其他Web重新访问数据库服务器。服务。在这种情况下,使用延迟加载可能不太好。一句小心的话,如果你变的懒惰加载的话,小心你得到的东西,它的方式很容易让你不去想这一点,并最终得到几乎整个数据库…

我已经看到许多性能问题是由于在休眠中错误地加载行为配置造成的。我想NHibernate的情况也差不多。我的建议是始终使用懒惰的关系,然后在查询(如fetch join)中使用热切的fetching语句。这样可以确保不加载太多数据,并且可以避免许多SQL查询。

通过查询很容易使懒惰的释放变得急切。从另一个角度看,这几乎是不可能的。