几天前，我们的团队讨论了灵活数据库实现的设计模式——Oracle、MYSql等。
我们讨论了桥接模式和抽象工厂模式。
我支持Abstract Factory，因为它灵活、易于实现，而且客户端不知道底层的DB实现是什么。但我的其他队友更喜欢Bridge而不是Abstract Factory。他们提到，当类层次结构增长时，它甚至更灵活，更容易维护。。
我仍然不满意为什么我们不能使用抽象工厂，我正在寻找你的建议和良好的参考，我可以比较这两种模式w.r.t不同的DB实现
正如前面所说，AbstractFactory是关于创造事物的。事实上，一个抽象工厂可以创建一个Bridge patern对象。因此，两者并不相互排斥。
就我个人而言，我发现Bridge在很多场景中都过于复杂，更喜欢在简单的外观模式后面抽象一些东西，比如在使用Repository模式时。
但是，如果您打算围绕多个实现类型定义一个标准操作，Bridge可能会更有用。在我看来，如果你只想创建一个抽象，让你在未来的某个时候交换到不同的后端，那就太过于工程化了。如果您打算在运行时使用不同的后端，那么这可能是合适的。
我不认为这两者是互斥的。抽象工厂是关于事物如何被创造的。直到事物被创造出来之后，桥才开始运作。
我认为抽象工厂就像是打电话给亚马逊并订购一些东西。亚马逊知道如何获得或制造这种东西，我并不关心它是如何发生的。
Bridge更像是物品将被放置的"盒子和包装材料的性质"。基本物品需要制作并装配在一起，抽象工厂是实现这一点的好方法。
如果我必须站在哪一边，我会更倾向于站在你这边，因为他们非常关心让具体的实现变得可变，以及通往它的路径如此迂回，这向我表明，一旦数据库对象最终创建，他们可能希望了解太多关于它的信息。如果有人希望它是全局可访问的，或者他们希望实现器从全局对象中获取实现，我不会感到惊讶。
如果严格控制对服务层的访问(例如，只允许Views向某些第三方(如Controller层)发出请求)，那么服务层是如何创建的以及它实际上是什么就无关紧要了——无论如何，只有一件事真正知道它。
如前所述，抽象工厂模式是一种创建对象的模式，桥接是一种结构模式，因此它们的使用并不互斥。
是使用桥接还是使用简单的策略模式来进行概括，归结为以下问题：
您需要在运行时切换策略吗？会被迫为每个策略创建多个实现类吗？
如果这两个问题中的任何一个都得到了肯定的答案，那么桥接模式很可能会让你受益。
如果下面的问题是真的，那么你可能需要一个抽象工厂。
是否需要在不知道具体类型的情况下创建实例？