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

Question

我一直在尝试通过阅读Martin Fowler的企业应用程序架构模式来了解有关设计模式的更多信息。我遇到了Table Data Gateway pattern并想知道如果你有涉及多个表的操作，你如何使用它？

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

这是一个具体的例子。如果我在两个表之间存在一对多关系，例如Questions和Choices（多项选择题），并且想要检索包含所有选项的问题。然后我会使用方法QuestionGateway创建一个find()类，但是我还有一个ChoiceGateway类，其方法findByQuestionId()可以检索问题的所有选项吗？

Answer 1

我建议更灵活地解释这种模式。你不应该感到有限或做出奇怪的决定只是为了与模式定义100％兼容。

请不要误解我的意思。我并没有建议抛弃模式。我实际建议的是以正确的方式使用它们。

回答你的问题：

• 如果您的ChoiceGateway和QuestionGateway之间没有那么多相互依赖关系，那么将它们分开是正常的。
• 如果存在相互依赖关系并且最好将这些表格加入＆＃34;加入＆＃34;从业务逻辑的角度来看，您可以创建类似于＆＃34; view＆＃34;的内容，例如将其称为QuiestionView。通过这种方式，您的业务逻辑可能会更加清晰，并且所有特定于DB的内容都将在定义的视图中封装。

基本上，这都是有用的抽象。如果您习惯使用这些表独立定义具有一些潜在重复的独立网关。如果你需要＆＃34;一切都在一个地方＆＃34;只需定义一些高级视图抽象。

BTW，模式本身不仅抽象表，而且抽象视图。因此，我认为没有理由可以使用定义的方法创建更高级别的抽象。

  

Table Data Gateway保存用于访问单个表或的所有SQL   查看

Answer 2

你对这种模式的概念是正确的。你的问题表明你也掌握了模式要解决的问题类型的更重要的概念。

表数据网关模式不适用于复杂数据模型，其中相关数据存储在多个表中。它适用于与数据库中任何其他数据无关的简单数据。它是专用键值存储时代之前的回归，当时人们希望在对关系模型没有用处的数据上享受ACID保证。正如您所注意到的，只要您关心数据之间的关系，模式就会降低。如果你想象自己曾想和另一个人一起JOIN这张桌子，不要使用这种模式。由于关系模型的整个要点是保留数据之间的关系，因此在实践中通常会避免这种关系。