design-patterns - 数据映射器和关系:实现策略？

Question

我几乎已经完成了Data Mapper，但是现在我要谈谈关系了。

我将在这里尝试说明我的想法。我找不到关于该主题的好文章/信息，所以也许我正在重新发明轮子(当然，我可以使用一个大框架-但我想通过这样做来学习)。

1:1关系

首先，让我们看一下1:1关系。通常，当我们拥有一个名为“Company”的域类和一个名为“Address”的域类时，我们的Company类将具有诸如address_id之类的内容。可以说，在大多数情况下，我们仅显示公司列表，并且仅当有人查看详细信息时才需要该地址。在那种情况下，我的数据映射器(CompanyDataMapper)只是延迟加载，这意味着它将仅从数据库中获取该address_id，但也不会进行联接以获取地址数据。

总的来说，我对每种关系都有一个 setter/getter 方法。因此，在这种情况下，有一个getAddress(Company companyObject)方法。它需要一个公司对象，查找它的地址属性，并且-如果它为NULL-使用该地址对象的Mapper类(AddressDataMapper)从数据库中获取相应的地址对象，并将该地址对象分配给指定对象的地址属性公司对象。

重要提示:是否允许数据映射器使用另一个数据映射器？

可以说，在大多数情况下，您既需要公司对象又需要地址对象，因为您总是将其同时显示在列表中。在这种情况下，CompanyDataMapper不仅会获取公司对象，而且还会使用JOIN进行SQL查询以获取地址对象的所有字段。最后，对记录集进行迭代，并将新对象及其相应的值提供给新对象，并将地址对象分配给公司对象。

到目前为止，听起来很简单。

1:n关系

这些怎么样？与1:1的唯一区别是，公司可能有多个地址对象。让我们看一下:当我们大多数时候只对Company感兴趣时，Data Mapper会将Company对象的地址属性设置为NULL。地址属性是一个数组，它可以不引用一个，一个或多个地址。但是我们还不知道，因为我们延迟加载，所以它只是NULL。但是，如果在大多数情况下我们也需要所有地址，该怎么办？如果我们要显示所有公司及其地址的大 list ？在这种情况下，事情开始变得非常丑陋。首先，我们不能为每个地址对象五十次加入地址表(我坚信这是不可能的，如果是的话，性能将低于零)。因此，当我们认为这很遥远时，在这种情况下就不可能懒惰地加载。

重要提示:这是真的吗？如果我有10个公司(每10个地址)，我是否必须发出100个查询以获取100个地址对象？

m:n关系

假设一个地址对象仅包含国家，州，城市，道路和门牌号。但是一所房子可能是一座巨大的商业塔，里面有很多公司。就像那些现代化的办公楼之一，任何人都可以租一小盘光碟在其网站上炫耀该塔。因此:许多公司可以共享相同的地址。

我还没有计划解决这种问题。

重要提示:也许这不是比1:n关系更大的问题？

如果有人知道有很好的资源详细介绍了解决/实现此资源的方法，那么我很乐意提供链接!

Answer 1

我期待您在该主题上得到的任何答案，但与此同时，为什么不直接跳至亚马逊(或您当地的图书经销商)并最终购买

Design Patterns: Elements of Reusable Object-Oriented Software，四人帮

Patterns of Enterprise Architecture，马丁·福勒

Domain-Driven Design: Tackling Complexity in the Heart of Software，埃里克·埃文斯

本书包含您在各种问题中所针对的原始模式，并被视为《设计模式和软件体系结构》中的引用著作。