Java 多数据库的Dao接口？

有一种模式是在

DAO实现之前创建
DAO接口
。我在谷歌上搜索了这种模式的优点，其中一个突出点是支持多个数据库

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

我的问题是，在什么情况下，我们可能需要支持多个数据库引擎来处理相同的数据？此外，如果出现这种需要，将如何管理
REST端点
，以支持不同的数据库

例如，
/db1/courses/
，
/db2/courses
，它们会像吗？如果我在这个问题上做了任何错误的假设或陈述，请纠正我。
我遇到过这样的情况，我必须检查两个数据库并获取数据。另一个数据库是备份数据库

这就是流程

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

我们可以随心所欲地设计，最终重要的是我们遵循坚实的原则。
基本上，高级组件不应该依赖于低级组件，但两者都应该依赖于抽象
 我只是想补充一下关于春季开发的答案。这是一件起初毫无意义的事情。你最终会问自己：


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

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


Spring数据-这是使用实体管理器的一种替代方法，在实体管理器中，您只定义接口，Spring将实际创建为您实现存储库功能的bean
设计-确保定义一个接口将有助于使您的存储库成为一个存储库
更容易的模拟——虽然可以说您仍然可以在Spring中这样做，而不需要定义接口，但是当您想用另一个实现替换实现时，它仍然更干净

但实际上这只是Spring的方式，如果您这样做，人们会发现理解您的代码更容易。
我将在这里介绍一个真实的示例

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

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

对于每个交互（如CustomerDAO），我们都有一个实现（CustomerDAO）

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

因此，CustomerDaoImpleOracle在CustomerDaoImpleSqlServer上重新实现。等等

我们学到的是：

接口提供了良好的抽象并允许多种实现
DAO层允许我们在必要时“切换”数据库（或其客户端库）
从业务逻辑中隐藏数据库的实现细节可以减少耦合和复杂性
休息与此无关。您不会根据代码读取数据的位置来设计RESTAPI。如果您构建的产品必须支持多个DB引擎，那么拥有多个DAO实现将非常有用。这并不意味着应用程序同时使用多个DB引擎。例如，这意味着client1使用Oracle，client2使用PostgreSQL。是的，我想知道如何分离这些客户端？我对端点的问题是受api版本控制的启发，在api版本控制中，我们可能有不同版本的端点。您将产品卖给client1，然后卖给client2，他们都配置并安装您的产品，选择一个受支持的DB引擎。如果它是web应用程序，而客户端没有安装任何东西，该怎么办？我们将如何区分哪个客户机想要使用哪个引擎@JBNizetYou正在询问拥有多个DAO实现的正当理由。我提供的是最常见的一个。仅仅因为您可以有多个实现并不意味着您应该这样做。如果你创建了一个web应用程序，并且你可以自由地使用你想要的数据库，那么就使用这个数据库，只需为每个DAO创建一个实现。但是最终应用程序只使用一个数据库来响应客户端？我说的对吗？不，它同时使用了这两种方法，它根据查询检查DB1是否有值，如果结果集为空，它将转到DB2。正如我所说，它使用DB2作为后备，我完全同意。