何时使用网关设计模式

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和集合...

- j-p

---

可能是需要一些关于模式（DAO x Gateway）的澄清的重复问题。 - Ahmed KRAIEM

这里很好地讨论了https://dev59.com/P3E85IYBdhLWcg3wXCW1 - Shailendra

Answer 1

网关模式

网关封装了面向对象的领域层和关系型持久化层之间的语义差异。

以上定义来自这里。

你所提到的Gateway也称为“服务”。服务层很重要，因为它提供了更高的抽象度和更“整体化”的方式来处理Person实体。

这个“额外”层的原因是系统中连接到Person的其他对象。例如，假设有Car对象，每个Person可能都有一辆车。现在，当我们出售一辆车时，我们应该更新“所有者”字段，进一步地，您还希望对涉及的Person对象执行相同的操作（卖方/买方）。

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

希望这能让事情更清晰。

- Nir Alfasi

---

有趣的是，它让事情变得更加混乱了 - 只是因为示例中有一个“personService”，而我没有包括它，因为我想先理解“gateway” - 而且很明显，“service”（在这个示例中）是对DAO或Gateway中任何方法的所有远程调用（再次强调 - 在这个示例中），所以说gateway就是service - 这确实让问题变得更加复杂，但我会尝试通过阅读上面所有的建议并提炼所有信息来使其适应 - 谢谢。 - j-p

@jpmyob 根据我阅读的不同来源，GW模式和服务具有相同的目的。我在答案中添加了GW的定义。可能还有其他例子，其中GW不是服务，但仍然被用于封装（隐藏）“幕后发生的事情”。即使你遇到一个GW看起来完全多余的例子 - 仍然有必要拥有它，因为产品的性质是发展和变得更加复杂，我们应该为未来做好规划，并设计我们的代码抽象和通用，这样在需要添加功能时就会更容易。 - Nir Alfasi

Answer 2

大多数的设计模式解释在某个时候会变得混乱，因为最初是由某个人命名和解释的，但随着时间的推移，出现了几种其他类似的模式，它们具有相似的用法和解释，但差别很小。这种微妙的差异就成了争论的来源:-)。关于网关模式，Martin Fowler在企业应用架构目录中提到了以下内容。我直接引用这里的内容：

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

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

当访问这样的外部资源时，通常会得到它们的API。然而，这些API自然会有些复杂，因为它们考虑了资源的性质。任何需要理解资源的人都需要理解它的API——无论是关系型数据库的JDBC和SQL，还是XML的W3C或JDOM。这不仅使软件更难理解，而且如果您将一些数据从关系型数据库转移到XML消息，则在将来的某个时候进行更改将变得更加困难。

答案是如此常见，以至于几乎不值得一提。将所有特殊的API代码封装到一个接口看起来像常规对象的类中。其他对象通过这个网关访问资源，网关将简单的方法调用转换为适当的专业API。

- Shailendra

Answer 3

网关设计模式在处理复杂的SDK、库或API时非常有用。为了使用它们，您可能需要一些实现，以便较低层不必了解它们，并且当然，这对其他层也不重要。在这种情况下，网关设计模式是最好的解决方案。您可以使用任何SDK或库来实现您想要的功能，然后通过合同，其他项目层可以轻松地使用网关。如果将来有一天您决定更改所提到的SDK或API，它不会影响整个项目。您只需更改网关实现，合同对其他层保持不变即可。

- Ehsan Mehranvari