我有一个在（有缺陷的）三层架构中实施的项目。我的工作是使其更通用，以便将新数据库添加到项目中。
具体：SQL 数据库有一个 databaseFacade，我必须使它更通用，这样我们就可以很容易地添加多个数据库。在这种情况下，将其写入 CSV 文件。
我在数据库层的想法是创建一个定义所有方法的接口。然后让数据库外观（取决于您要使用的）实现此接口，使其变得更加通用。 然后我有某种 DBmanager 类。这个 DBmanager 类将读出一个配置文件，以便他知道要使用什么数据库。根据这些信息，他将创建一个接口实例并将其返回给应用层。
但是，这是我不知道我是否正确的地方。应用层现在有一个 DBmanager 类（其中所有内容都被正确封装，只有一个公开的方法用于返回外观），然后是 DBfacade。
关于这个的正确性有什么想法吗？因为我有疑问。
【问题讨论】：
标签： java architecture 3-tier
我已经看到一个 PHP 系统 (Moodle) 几乎完全使用这种模式并且它运行良好。所发生的只是将 DB 类型指定为配置变量，并将具体的 DB 访问类实例化为全局 DB 管理器对象，提供外观方法，例如get_records()，它返回一个标准化的行对象数组。你是否会称这个外观或适配器是有争议的，但这并不担心。
我会说按照你目前的计划去做。您似乎已经正确地解耦了这些层并理解了模式的目的。此外，您的低级（DB）和高级（应用程序控制器）组件都依赖于中间的单个 DB 外观接口的方式是 dependency inversion 的一个很好的例子，所以加分！ :)
【讨论】：
这是正确的方法。一个小问题是您的 DBManager 实际上遵循Factory 模式，因此应该称为 DatabaseFacadeFactory，假设您的外观类称为 DatabaseFacade。
随着您对 Java 的熟悉程度越来越高，请查看 Spring。它提供了许多工具和技术来自动处理此类情况，并消除对大部分样板代码的需求。如需更多信息，请参阅dependency-injection。
【讨论】：
对我来说，这似乎是合法的。我还不是软件架构方面的专家，但与 JDBC 的设计方式相比，您的描述描述了类似的概念。
【讨论】：