当有许多关联时使用像 NHibernate 这样的 ORM - 性能问题

Posted 2023-04-12

【中文标题】当有许多关联时使用像 NHibernate 这样的 ORM - 性能问题

【英文标题】：Usage of ORMs like NHibernate when there are many associations - performance concerns

【发布时间】：2009-04-11 14:28:14

【问题描述】：

我创建了一个应用程序（基于 Web 的应用程序），它现在具有大量关联。简单地说，一个帐户：

有很多用户 有设置 有很多项目

类似的项目：

有很多项目

一个用户：

有很多任务

等等，加载更多的关联。我希望没有什么特别不寻常的。我选择使用 NHibernate 为我提供了一组不错的持久类，其中映射器定义了所有关联。

但是这种方法对吗？在对应用程序的每次请求时，都会加载帐户（因为需要它），然后从数据库中请求大量不需要的数据。延迟加载是一种选择，但我不知道我的初始方法是否更好。在那个阶段我想要的只是帐户和相关设置，那么映射是否应该反映这一点？问题是我想要其他点的帐户的所有项目之类的东西，所以我需要映射器来反映所有的关联。

我担心延迟加载可能只是弥补了我糟糕的初始架构。我很清楚这可能只是由于我对 NHibernate 的内部工作原理知之甚少。因此，我将不胜感激任何有关良好做法的建议。

【参考方案1】：

领域驱动设计在理解这些情况时帮助了我很多。 Association in DDD

在您的情况下您应该问自己的问题：您真的需要双向关联 - 或者在某些情况下单向关联就足够了吗？这个决定是架构的一部分。所以你是对的。默认情况下选择双向关联时，延迟加载有很大帮助。但它可以被认为是一个设计缺陷。

【参考方案2】：

默认情况下，NHibernate 为大多数关联和对象启用延迟加载通常是一种很好的做法，除非您知道您总是需要关联的数据。然后，当您进入优化阶段时，您可以选择性地切换到预先加载的项目，以便更有效地加载。

【参考方案3】：

嗯，在我看来，您的架构看起来很健康。协会很好。

考虑替代方案：

更少的关联：会导致糟糕的数据库设计 不要使用 ORM：你会发现自己在做“惰性初始化”——反正有点编码

一切看起来都很好，延迟初始化也很好 :) - 但是，有很多现实生活中的使用陷阱：

在使用延迟初始化的东西之前不要关闭会话（这将要求您“破解”您的关联上的一些无用的阅读语句以强制阅读它） 使用 NHibernate，您需要使用它执行所有 DAL 活动才能启用二级缓存 您将有一些开销（如果我不想知道帐户名，只想知道其中的用户怎么办）

这就是 ORM 的工作方式。他们有优点（更容易开发，避免大量样板代码）和缺点（更多开销，更少灵活性）。