将导航属性声明为延迟加载，但急于加载它。 不好的做法？

Question

我们所有的导航属性都定义为虚拟（延迟加载），但是大多数都渴望加载（.include），因此延迟加载的灵活性是否对性能产生了影响？ 我们是否应该仅在真正需要进行延迟加载时才进行延迟加载？

谢谢。

Answer 1

快速基准测试（在对象图中加载数千个对象）表明，启用或禁用延迟加载和代理生成时，加载时间没有明显差异。

但是，当您知道确实渴望加载（并可能使用短时上下文）时，我总是会关闭延迟加载和代理生成。

context.Configuration.LazyLoadingEnabled = false;
context.Configuration.ProxyCreationEnabled = false;

即使它不能显着提高性能，但至少它消除了上下文超出范围时触发惰性加载的风险，或消除了对象序列化时惰性加载级联的风险。

在您的情况下，当优先加载时，您甚至可以将其设置为默认值，即在构造函数中将这些属性转换为上下文类。

请注意，使用AsNoTracking()获取对象时确实会获得性能，这是在获取用于只读目的的对象时的一种很好的做法。 这种情况经常发生：在断开连接的设置中，例如当对象序列化到Web客户端时，即使客户端可能能够修改对象，上载也始终是只读的。 更改将在后期操作中处理。

Answer 2

这取决于您为什么要处理返回的对象。 当您尝试访问导航属性时，延迟加载将导致新查询被发送到数据库。

如果您希望加载该对象以包含其所有导航属性，然后再从不使用它们，则可以。 您正在从数据库请求更多数据，然后必须花费更多时间来解析它们。 当然，反之亦然。

如果从数据库中获取一个对象并开始访问导航属性，则必须在数据库中查询它们，从而导致出现n + 1个查询。 我要说的是，这比批量查询记录要昂贵得多，但实际上取决于您知道如何将对象用于特定操作。

就个人而言，在Web环境中，我渴望加载，因为上下文是短暂的。 在桌面环境中，您可以使整个应用程序会话的上下文保持活动状态，我将使用延迟加载，因为您不必一遍又一遍地为后续查询构建上下文。