3层架构的正确性

Question

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

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

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

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

有关此正确性的任何想法？因为我有疑虑。

Answer 1

我已经看到PHP系统（Moodle）几乎使用了这种模式，它运行正常。所有发生的事情是将DB类型指定为配置变量，并将具体的DB访问类实例化为全局数据库管理器对象，提供外观方法，例如get_records（），返回标准化的行对象数组。无论你是否会称这个外观或适配器，这都是可以辩解的，但这几乎不用担心。

我会说你现在的计划。您似乎已经正确地解耦了图层并理解了图案的用途。此外，低级别（DB）和高级别（应用程序控制器）组件在中间依赖于单个数据库外观界面的方式是dependency inversion的一个很好的例子，所以奖励积分！ ：）

Answer 2

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

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

Answer 3

对我来说，它似乎是合法的。我还不是软件架构方面的专家，但与JDBC的设计方式相比，您的描述描述了类似的概念。