何时使用Gateway设计模式

Question

在试图让我的头脑进入一些设计模式时，我遇到了让我感到困惑的样本 - 希望这很容易解释，而我只是错过了它。

我的问题是“在哪里”网关适合这个？这似乎是多余的，作为一个附加的数据访问点。

示例代码有三个类 -

1. person - 其中包含每个对象属性的getter和setter方法
2. personDAO - 有数据调用来执行CRUD。
3. personGateway - 有getAll和getCount - 这些也是数据通话...... ???

我完全对数据进行DAO调用，DAO使用“person”类创建一个要传回的对象 - 但是为什么不将getAll和getCount放在DAO中？ ??

“网关”在这个游戏中扮演什么逻辑位置？

---阅读回复后添加---

好的 - 我在搜索时显然错过了这一点 - 它确实“帮助”澄清 - Need some clarification with Patterns (DAO x Gateway) - 但是，它似乎非常以java为中心，它实际上跳过了我希望的区别 -

我想答案是DAO返回一个“对象”而一个“对象”是一个单独的实体......而不是一个集合。如果你正在重新收集一个集合（如果你“应该”它就有争议），那么你就可以使用网关......但是在任何情况下你都不应该用收集来混淆DAO ......

Answer 1

网关模式

  

网关封装了面向对象之间的语义鸿沟   域层和面向关系的持久层。

取自here。

的定义

示例中的网关也称为“服务”。服务层很重要，因为它在处理Person实体时提供了更高的抽象和更“整体”的方式。

此“额外”图层的原因是系统中连接到Person的其他对象。例如，假设有Car个对象，每个人可能有一辆汽车。现在，当我们出售汽车时，我们应该更新“所有者”字段，进一步你要为所涉及的Person对象（卖方/买方）做同样的事情。

为了以OO方式实现这种“级联”（没有耦合对象实现）BuyCarService将更新新的所有者：服务将按顺序调用CarDAO和PersonDAO更新数据库中的相关字段，以便DAO不必相互“知道”，从而解耦实现。

希望这会让事情更加清晰。

Answer 2

大多数设计模式解释在某些时候或其他时候变得混乱，因为最初它是由某人命名和解释但在适当的时候出现了几个其他类似的模式，它们具有相似的用法和解释，但差别很小。这种微妙的差异然后成为辩论的来源:-)。关于Gateway模式，这是Martin Fowler在企业应用程序架构目录中提到的内容。我直接引用here

  

“网关 - 封装对外部系统或外部系统的访问的对象   资源“。

     

有趣的软件很少孤立存在。即使是最纯粹的   面向对象的系统经常要处理那些没有的东西   对象，例如关系数据库表，CICS事务和   XML数据结构。

     

当访问这样的外部资源时，您通常会获得API   对他们来说但是，这些API自然会有所不同   因为它们考虑了资源的性质而变得复杂。   任何需要了解资源的人都需要了解其API    - 用于相关数据库的JDBC和SQL，还是用于XML的W3C或JDOM。它不仅使软件更难理解，而且还使它变得更难理解   如果你从一个数据转移一些数据，也会更难改变   在将来的某个时刻将关系数据库转换为XML消息。

     

答案很常见，几乎不值得说明。包裹所有的   特殊的API代码到一个接口看起来像常规的类中   宾语。其他对象通过此网关访问资源   将简单的方法调用转换为适当的专用   API。

Answer 3

当您想要使用复杂的SDK，库或API时，网关设计模式非常有用。要使用它们，您可能需要一些实现，较低层不必了解它们，当然，这对其他层并不重要。在这种情况下，网关设计模式是最佳解决方案。你可以用任何SDK或库实现你想要的东西，然后通过合同，其他项目层可以很容易地与网关一起工作。如果有一天你决定更改提到的SDK或API，它不会影响整个项目。您只需更改网关实施，其他层的合同将保持不变。