使用存储库模式处理集合的说明

Question

如果您有两个处理关系数据库持久性的存储库，则处理“Person”对象的personrepository以及处理“Address”对象的地址库以及人员对象有一个地址集合（可能是延迟加载）。显然，personrepository将用于保持对个人对象的更改，addressrepository将用于保留对地址对象的更改，但是负责持续更改个人地址集合的内容是什么？

什么策略可用于持久修改个人对象地址集合回数据库？这个责任在哪里存在于仓库中（即使在数据库中它就是存储链接到一个人的地址的人员仓库）？

我应该提到，这不是使用ORM。

感谢您的任何帮助，任何战略/澄清将不胜感激。

Answer 1

有点耐人寻味：

有真的，你需要决定如何解决这一问题之前，回答以下两个问题：

1. 能的地址没有一个人存在吗？
2. 地址可以由多个人拥有吗？

如果1.的答案是否定的，并且2.的答案是否定的 - 你不应该有一个AddressRepository，并且Person应该负责将地址保存在一个正常的1对多关系中地址中的外键。否则，Person会突然负责删除地址 - 或需要对AddressRepository进行引用 - IMO将以可怕的混乱响应结束。

如果1.的答案是否定的，并且2.的答案是肯定的 - 你有多对多的关系，人应该保持这种多对多的关系（因为这是唯一的关系）知识需要坚持下去）。

如果1.的答案是肯定答案，而2.答案是否定的 - 地址应该负责更新关系 - 并且应该有合作伙伴属性，因此对象中的关联是单向的。

最后 - 如果两者都是 - 您再次有多对多的关系，但这次让地址处理多对多关联更合理。

我希望这可以帮助你决定:)

Answer 2

地精是正确的，很少有情景我可以想像这将要求你可能想摆脱它的AddressRepository。

这就是说，您要查找的设计概念是“Aggregate Root”。这很快就意味着要识别对象图中没有其他对象不存在的对象。这些是需要存储库的类，它们最终将成为对象图的网关。

当我第一次了解它时，这让我感到困惑 - 我不认为识别这些对象会这么简单。出路是“Bounded Context”的附加概念。这可能是最不适用的设计原则。

总之，考虑你正在解决以下两个用户故事。

• 正如我希望能够在网站上存储所有之前的送货地址，以便我可以下订单
• 作为物流管理员时访问它们更易于用户想打印出所有地址的，我们需要运送到明天，这样我可以计划航线相应

所以，你已经得到的东西像下面的模型：

这似乎很难解剖。如果Person是根，那么当用户只是简单地改变他们的信息时，我们必须用Orders关联加载Person对象。如果他们下了很多订单（比如他们为公司管理库存），这可能会成为一个巨大的性能问题。

选择订单作为聚合根也不能解决问题。如果订单没有对某人的引用，那么我们将如何检查所选地址是否有效？

另一方面：旧学校对这些问题的回答分别是“懒加载”和“双向关联”。然而，这些技术都伴随着他们自己的复杂问题，我相信他们通常比他们的价值更麻烦。

解决这个看似冲突的原因（为什么我觉得我在沟通Eliyahu Goldratt？）就是承认这两个故事存在于不同的意义上下文中。当用户存储地址时，他们不关心订单，同样，当管理员正在检查地址时，他们并不关心它的用途。定义有冲突。当两种情境都说“地址”时，他们指的是相同的物理对象，但只是作为两个完全不同概念的试金石！就个人而言，地址只是他们存储的一个测试块。就物流经理而言，地址唯一的要求应该是与真实地点相关联。

那么为什么即使他们是同一个对象呢？

你看到发生了什么？您已经将问题分解为两个离散的和不相关的系统，正如我们现在所知道的那样，小型，离散和集中的系统是可维护软件的关键。

那么当这些上下文需要沟通时会发生什么？由于两个上下文中的地址对象可能在不同的时间使用（并且其中一个是只读的），因此可以使用相同的数据库。但是，这并不推荐（尽管很多人反正这样做）。相反，两个域上下文之间的通信应该通过显式消息传递和映射机制（例如事件聚合器/消息传递总线）（如果有人知道两者之间的区别）来在代码中处理。