我一直试图通过阅读 Martin Fowler 的企业应用架构模式来了解更多关于设计模式的信息。我遇到了Table Data Gateway pattern，想知道如果您的操作涉及多个表，您将如何使用它？
我的理解是每个表都有自己的类。每个类都会有访问单个表的 SQL 语句，但是当我的某些语句依赖于其他表时会发生什么？
这是一个具体的例子。如果我有两个表之间的一对多关系，例如Questions 和Choices（多项选择题），并且想检索一个包含所有选项的问题。然后我会有一个 QuestionGateway 类和一个方法 find() 但我也会有一个 ChoiceGateway 类和一个方法 findByQuestionId() 来检索问题的所有选择吗？
【问题讨论】：
标签： design-patterns
我建议对这种模式进行更灵活的解释。您不应该仅仅为了与模式定义 100% 兼容而感到受限或做出奇怪的决定。
请不要误会我的意思。我不建议扔掉模式。我实际上建议的是以适当的方式使用它们。
回答你的问题：
ChoiceGateway 和QuestionGateway 之间没有太多相互依赖关系，则将它们分开是正常的。QuiestionView。通过这种方式，您的业务逻辑可能会更清晰一些，并且所有特定于数据库的内容都将封装在定义的视图中。基本上，这都是关于有用的抽象。如果您对使用这些表感到满意，请独立定义具有一些潜在重复的独立网关。如果您需要“一切都在一个地方”，只需定义一些高级视图抽象即可。
顺便说一句，模式本身不仅抽象表，还抽象视图。所以我认为你没有理由不能使用定义的方法创建更高级别的抽象。
表数据网关包含用于访问单个表的所有 SQL 或 查看
【讨论】：
您对这种模式的概念是正确的。您的问题表明您还掌握了该模式旨在解决的问题类型的更重要的概念。
表数据网关模式不适用于相关数据存储在多个表中的复杂数据模型。它适用于与数据库中的任何其他数据没有关系的简单数据。这是专用键值存储时代之前的倒退，当时人们希望在对关系模型没有用处的数据上享受 ACID 保证。正如您所注意到的，只要您关心数据之间的关系，模式就会退化。如果您想象自己曾经想用另一个JOIN 这张桌子，请不要使用这种模式。由于关系模型的重点是保留数据之间的关系，因此在实践中通常会避免这样做。
【讨论】：