DB封装的设计模式 - 桥与抽象工厂

Question

几天前，我们的团队正在讨论灵活的数据库实现的设计模式 - Oracle，MYSql等。

我们讨论了Bridge模式和抽象工厂模式。

我赞成抽象工厂，因为它灵活，易于实现，客户端不知道底层的数据库实现是什么。但我的其他队友更喜欢Bridge over Abstract Factory。他们提到当类层次结构增长时，它更加灵活且易于维护。

我仍然不满意为什么我们不能使用抽象工厂，我正在寻找你的建议和良好的参考，我可以比较两种模式w.r.t 不同的数据库实现。

Answer 1

我不认为这两者是相互排斥的。抽象工厂是关于如何创造事物的。在创建完成之后，Bridge才会启动。

我认为抽象工厂就像调用亚马逊并订购一些东西一样。亚马逊知道如何获取或制作该东西，并不关心我是如何发生的。

Bridge更像是“放置物品的盒子和包装材料的性质”。基础物体需要制作并装配在一起，而抽象工厂是实现这一目标的好方法。

如果我不得不站在一边，我会更倾向于倾向于你，因为他们非常关心如何使具体的实施变得可变，而且它的路径如此迂回向我暗示可能他们想要在数据库对象最终创建后要了解太多东西。如果有人想让它成为globally accessible，或者他们希望实现者能够从全局对象中获取并从中获取实现，我不会感到惊讶。

如果您继续访问受到严格监管的服务层（例如，只允许View发出某些第三方的请求，例如Controller层），那么服务层的创建方式和实际内容的重要性就会大大降低是的 - 无论如何只有一件事真正了解它。

Answer 2

如前所述，抽象工厂模式是一种创建对象的模式，而Bridge是一种结构模式，因此它们的用法并不相互排斥。

使用概括来使用Bridge还是简单的策略模式可归结为以下问题：

您是否需要在运行时切换策略？ 是否会被迫为每个策略创建多个实现类？

如果这两个问题中的任何一个产生肯定答案，那么Bridge模式可能会让您受益。

如果以下问题属实，那么您可能需要一个抽象工厂。

您是否需要在不知道具体类型的情况下创建实例？

Answer 3

如前所述，AbstractFactory是关于创造事物的。实际上，抽象工厂可以创建Bridge patern对象。所以两者并不相互排斥。

就个人而言，我发现Bridge在很多情况下都过于复杂，而且更喜欢在简单的外观模式背后抽象出来，例如在使用Repository模式时。

但是，如果您打算围绕多种实现类型定义标准操作，Bridge可能会更有用。在我看来，如果你只是想创建一个允许你在将来某个时候交换到不同后端的抽象，那就过度工程了。如果您打算在运行时使用不同的后端，那么它可能是合适的。