0

来自 DDD：解决软件核心的复杂性（第 177 页）：

添加处理事件时需要更新交付历史记录会导致交易中涉及的 Cargo AGGREGATE。

a）在页面下方作者确实提出了一个替代解决方案，但仍然 - 上述摘录中的作者不是在本质上建议我们通过每次访问该属性时让属性查询数据库（通过存储库）来实现关联吗？DeliveryHistory.Events

b）由于作者“提出”的实现几乎与延迟加载的实现方式相同（除了延迟加载仅在我们第一次需要数据时查询数据然后缓存它），我还会问以下问题：

许多人通常反对延迟加载，但无论如何，我认为如果相关实体驻留在同一个聚合中，我们不应该使用延迟加载，因为这样的关联是用对象引用表示的，当我们需要事务完整性时实现？

原因是如果从不访问相关数据（因此从不检索），这种完整性可能会受到损害，因为在修改聚合时不能正确执行不变量？

更新：

一种）

当存储库加载 DeliveryHistory 实体时，可以加载 DeliveryHistory.Events 集合。它也可以通过延迟加载来加载，在这种情况下，ORM 会注入一个集合代理，该集合代理在迭代时会调用数据库。

但是作者不是提出了第三种选择，即每次访问（或者每次调用）都查询事件吗？DeliveryHistory.EventsDeliveryHistory.GetEvents()

b)

它类似于延迟加载，但重要的区别在于，借助存储库查询可以省略对象模型中的 Events 属性。这减少了 DeliveryHistory 实体的“足迹”。

我-我假设通过“类似于延迟加载”，您指的是每次请求事件时都从数据库中检索事件的设计？！

II - 无论如何，如果我们省略该DeliveryHistory.Events属性（并且可能没有定义为替代 a DeliveryHistory.GetEvents()），那么我们如何实现作者提出的设计（如我原来的帖子中所述，我知道在页面作者的下方是否提出了更好的选择）？

谢谢

4

1 回答 1

1

a)DeliveryHistory.Events当存储库加载 DeliveryHistory 实体时，可以加载集合。它也可以通过延迟加载来加载，在这种情况下，ORM 会注入一个集合代理，该集合代理在迭代时会调用数据库。

b) 它类似于延迟加载，但重要的区别在于，借助存储库查询可以省略对象模型中的 Events 属性。这减少了DeliveryHistory实体的“足迹”。

延迟加载的问题不是数据可能永远不会被访问，而是第一次访问延迟加载的属性会导致数据库调用，您必须确保连接仍然存在。从某种意义上说，这可能会损害应该被视为一个整体的聚合的完整性。

更新

a) 无论哪种方式，最终结果都是相同的。我不确定创建代理集合是否是本书写作时使用的一种技术（2003 年）。

b1) 是的，它们的相似之处在于事件不与 DeliveryHistory 实体一起加载，而只是按需加载。

b2) 将通过调用存储库来访问事件，而不是 DeliveryHistory 实体上的 events 属性。存储库本身将由周围的应用程序服务调用。它将检索事件并将它们传递到需要它们的地方。或者，如果用例正在添加事件，应用程序服务将调用存储库来持久化事件。

于 2013-02-06T22:59:10.397 回答