Design patterns 如何使用涉及一对多关系的表数据网关模式？

我一直试图通过阅读Martin Fowler的《企业应用程序体系结构模式》来了解更多关于设计模式的知识。我遇到了，想知道如果有涉及多个表的操作，如何使用它

我的理解是每个表都有自己的类。每个类都有用于访问单个表的SQL语句，但是当我的一些语句依赖于其他表时会发生什么呢

---

这里有一个具体的例子。如果我在两个表之间有一对多关系，例如

问题

和

选择

（多项选择问题），并且希望检索一个问题及其所有选择。然后我会有一个

QuestionGateway

类，它有一个

find（）

方法，但我也会有一个

ChoiceGateway

类，它有一个

findByQuestionId（）

方法，来检索问题的所有选项？

你对这个模式的概念是正确的。您的问题表明，您还掌握了该模式要解决的问题类型的更重要的概念

---

表数据网关模式并不适用于相关数据存储在多个表中的复杂数据模型。它适用于与数据库中的任何其他数据都没有关系的简单数据。这是从专用键值存储时代之前的倒退，当时人们希望对不使用关系模型的数据享受ACID保证。正如您所注意到的，只要您关心数据之间的关系，模式就会退化。如果您想象自己曾经想要将此表与另一个表连接起来，请不要使用此模式。由于关系模型的全部要点是保留数据之间的关系，因此在实践中通常避免使用关系模型。

我建议更灵活地解释这种模式。你不应该仅仅为了100%符合模式定义而感到受限或做出奇怪的决定

请不要误会我。我不是建议扔掉模式。我实际上建议的是以适当的方式使用它们

回答你的问题：

• 如果您的

  ChoiceGateway

  和

  QuestionGateway

  之间没有太多的相互依赖关系，将它们分开是正常的
• 如果存在相互依赖关系，并且最好从业务逻辑的角度“连接”这些表，那么您可以创建类似“视图”的内容，例如，将其称为

  QuiestionView

  。通过这种方式，您的业务逻辑可能会更加清晰，所有特定于DB的内容都将包含在已定义的视图中

基本上，它都是关于有用的抽象。如果您对独立地使用这些表感到满意，请定义具有一些潜在重复的独立网关。如果您需要“一切都在一个地方”，只需定义一些高级视图抽象

顺便说一句，模式本身不仅抽象表，而且抽象视图。所以我认为没有理由不能使用已定义的方法创建更高级别的抽象

表数据网关包含用于访问单个表或表的所有SQL 查看

---

你对我应该研究的其他模式有什么建议吗？@Mikey当然有。没有特定顺序：装饰器、工厂、构建器、抽象工厂、控制反转（从技术上讲不是模式，而是非常有用的设计概念）、适配器、服务定位器和线程池。这些都很有用。