多数据库的道接口？答案

【问题标题】：Dao interface for multiple databases?多数据库的道接口？
【发布时间】：2019-04-13 22:10:57
【问题描述】：

有一种在DAO implementation 之前创建DAO interface 的模式。我在 Google 上搜索了这种模式的优点，其中一个引人注目的地方是支持多个数据库。

现在，我可以理解的是，这里的多个数据库意味着不同的数据库引擎，而不是多个数据源。显然，多个数据源不应该影响 DAO 实现是如何由 DAO 接口组成的。

我的问题是，在哪些情况下我们可能需要支持多个数据库引擎来满足相同的数据？另外，如果出现这种需求，REST endpoints 将如何管理以支持不同的数据库？

他们会喜欢吗？ /db1/courses/, /db2/courses ?如果我在这个问题中做出任何错误的假设或陈述，请纠正我。

【问题讨论】：

REST 与此无关。您不会根据代码读取数据的位置来设计 REST API。如果您构建的产品必须支持多个数据库引擎，那么拥有多个 DAO 实现会很有用。这并不意味着应用程序一次使用多个数据库引擎。比如client1使用Oracle，client2使用PostgreSQL。
是的，我想知道如何分离这些客户？我对端点的问题受到 api 版本控制的启发，我们可能有不同版本的不同端点。
您将产品卖给 client1，然后将其卖给 client2，他们都配置和安装您的产品，选择支持的数据库引擎之一。
如果它是一个 Web 应用程序并且客户端没有安装任何东西怎么办？我们将如何区分哪个客户端想要打哪个引擎？ @JBNizet
您要求有多个 DAO 实现的正当理由。我提供的是最常见的一种。仅仅因为你可以有多个实现并不意味着你应该这样做。如果您创建了一个 Web 应用程序，并且您可以随意使用所需的数据库，那么请使用该数据库，然后为每个 DAO 创建一个实现。

标签： java spring rest software-design

【解决方案1】：

我遇到了这种情况，我必须检查两个数据库并获取数据。另一个数据库是备份数据库。

所以这就是流程。

  RestController --> Service --> DBService 
                                           --> DB1Repository --> Connect to DB1
                                           --> DB2Repository --> Connect to DB2

我们可以随心所欲地设计，最终重要的是我们遵循 SOLID 原则。基本上，高级组件不应该依赖于低级组件，而两者都应该依赖于抽象。

【讨论】：

但是最后的应用只用了一个数据库来响应客户端？我说的对吗？
不，它同时使用两者，它检查 DB1 是否有根据查询的值，如果结果集为空，则转到 DB2。正如我所说，它使用 DB2 作为后备。

【解决方案2】：

我只是想补充一下关于开始 Spring 开发的答案。这是一开始最初没有意义的事情之一。你最终会问自己：

将只有 1 个数据库，所以这没有意义，为什么要这样做？
当只有 1 个实现时，我为什么要定义一个接口？

但实际上，这些都不是你这样做的真正原因。但这是惯例和模式，这种风格正是人们习惯的风格，你会更喜欢它。还有其他一些原因：

Spring Data - 这是使用实体管理器的替代方案，您只需定义接口，Spring 将实际创建为您实现存储库功能的 bean。
设计 - 确保定义接口将有助于将存储库保持为存储库。
更容易模拟 - 虽然可以说您仍然可以在 Spring 中执行此操作而无需定义接口，但当您想用另一个实现替换实现时仍然更简洁。

但实际上这只是 Spring 的方式，如果你这样做，人们会发现你的代码更容易理解。

【讨论】：

我完全同意。

【解决方案3】：

我会在这里描述一个真实世界的例子。

我们最近想将一个大型生产数据库 (Oracle) 更改为另一个 (SQL Server)。

对于数据库的不同区域，我们有不同的 DAO 接口和实现。例如 CustomerDAO、AccountsDAO 等。

对于每个接口（如 CustomerDAO），我们都有一个实现 (CustomerDAOImplOracle)。

对于我们来说，编写 DAO 的 SQL Server 版本（SQL 语法和 jdbc 库当然不同）并在对我们的业务逻辑（使用 DAO 的服务）进行最小更改的情况下交换它们是相对简单的。

因此，CustomerDAOImplOracle 在 CustomerDAOImplSQLServer 上重新实现。等等……

我们学到了什么：

接口提供了良好的抽象并允许多种实现
DAO 层允许我们在必要时“切换”数据库（或其客户端库）
从业务逻辑中隐藏数据库的实现细节可以减少耦合和复杂性

【讨论】：