3层架构正确性

Question

我有一个在(有缺陷的)3层架构中实现的项目。我的工作是让它更通用，这样就可以很容易地将新数据库添加到项目中。

具体:有一个用于SQL数据库的databaseFacade，我必须使它更通用，这样我们就可以非常容易地添加多个数据库。在这种情况下，将其写入CSV文件。

我在数据库层的想法是创建一个接口，其中定义了所有方法。然后让数据库外观(取决于您想要使用哪一个)实现此接口，以便它变得更加通用。然后我有了某种DBmanager类。这个DBmanager类将读出一个配置文件，以便他知道要使用哪个数据库。基于此信息，他将创建接口的一个实例，并将其返回给应用层。

然而，这是我不知道我是否正确的地方。应用程序层现在有一个DBmanager类(其中所有内容都被正确封装，只有一个方法是公共的，用于返回facade)，然后是DBfacade。

对这一点的正确性有什么想法？因为我心存疑虑。

Answer 1

我见过一个PHP系统(Moodle)使用几乎完全相同的模式，它工作得很好。所发生的一切是DB类型被指定为配置变量，而具体的DB访问类被实例化为全局DB管理器对象，从而提供外观方法，例如get_records()，它返回一个标准化的行对象数组。您将把这个facade称为facade还是adapter，这是有争议的，但这几乎不是一个问题。

我要说的是按照你现在的计划去做。您似乎已经正确地解耦了各个层，并且理解了模式的用途。此外，您的低级( DB )和高级(应用程序控制器)组件都依赖于中间单个DB facade接口的方式是dependency inversion的一个很好的例子，因此这是一个很好的加分！:)

Answer 2

这才是正确的方法。一个小问题是，您的DBManager实际上遵循Factory模式，因此应该称为DatabaseFacadeFactory，假设您的外观类称为DatabaseFacade。

随着您对Java越来越熟悉，请查看Spring。它提供了许多工具和技术来自动处理这样的情况，并消除了对大部分样板代码的需要。有关详细信息，请参阅dependency-injection。

Answer 3

对我来说，这似乎是合法的。我还不是软件体系结构方面的专家，但是您的描述描述了与JDBC是如何设计的类似的概念。