什么时候应该避免使用 NHibernate 的延迟加载功能? [英] When should one avoid using NHibernate's lazy-loading feature?

问题描述

我听到的关于 NHibernate 延迟加载的大部分内容是，使用它比不使用它更好.为了减少瓶颈，最小化数据库访问似乎是有意义的.但是很少有事情是不折不扣的，当然它通过强制您拥有 virtual 属性来稍微限制了设计.但我也注意到一些开发人员对某些常用对象关闭了延迟加载.

Most of what I hear about NHibernate's lazy-loading, is that it's better to use it, than not to use it. It seems like it just makes sense to minimize database access, in an effort to reduce bottlenecks. But few things come without trade-offs, certainly it slightly limits design by forcing you to have virtual properties. But I've also noticed that some developers turn lazy-loading off on certain often-used objects.

这让我想知道是否在某些特定情况下使用延迟加载会损害数据访问性能.

This makes me wonder if there are some definite situations where data-access performance is hurt by using lazy-loading.

所以我想知道，我应该在什么时候以及在什么情况下避免延迟加载我的 NHibernate 持久化对象之一?

So I wonder, when and in what situations should I avoid lazy-loading one of my NHibernate-persisted objects?

延迟加载的缺点仅仅是额外的处理时间，还是 nhibernate 延迟加载也会增加数据访问时间(例如，通过对数据库进行额外的往返)?

Is the downside to lazy-loading merely in additional processing time, or can nhibernate lazy-loading also increase the data-access time (for instance, by making additional round-trips to the database)?

谢谢！

推荐答案

从数据库中加载对象和延迟加载对象之间存在明显的性能权衡.

There are clear performance tradeoffs between eager and lazy loading objects from a database.

如果您使用预先加载，您会在单个查询中吸收大​​量数据，然后您可以缓存这些数据.这在应用程序启动时最为常见.您正在为数据库往返交换内存消耗.

If you use eager loading, you suck a ton of data in a single query, which you can then cache. This is most common on application startup. You are trading memory consumption for database round trips.

如果你使用延迟加载，你在单个查询中吸收的数据量最少，但是任何时候你需要更多与初始数据相关的信息时，它需要对数据库进行更多的查询，并且数据库性能命中通常是主要的性能大多数应用的瓶颈.

If you use lazy loading, you suck a minimal amount of data in a single query, but any time you need more information related to that initial data it requires more queries to the database and database performance hits are very often the major performance bottleneck in most applications.

因此，一般而言，您总是希望准确检索整个单元所需的数据工作"，不多也不少.在某些情况下，您可能不确切地知道自己需要什么(因为用户正在通过向导或类似的方式工作)，在这种情况下，您可以随时延迟加载.

So, in general, you always want to retrieve exactly the data you will need for the entire "unit of work", no more, no less. In some cases, you may not know exactly what you need (because the user is working through a wizard or something similar) and in that case it probably makes sense to lazy load as you go.

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

If you are using an ORM and focused on adding features quickly and will come back and optimize performance later (which is extremely common and a good way to do things), having lazy loading being the default is the correct way to go. If you later find (through performance profiling/analysis) that you have one query to get an object and then N queries to get the N objects related to that original object, you can change that piece of code to use eager loading to only hit the database once instead of N+1 times (the N+1 problem is a well known downside of using lazy loading).

这篇关于什么时候应该避免使用 NHibernate 的延迟加载功能?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！