2

我有一个在（有缺陷的）三层架构中实现的项目。我的工作是使它更通用，以便将新数据库添加到项目中。

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

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

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

关于这个的正确性有什么想法吗？因为我有疑问。

4

3 回答 3

1

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

随着您对 Java 越来越熟悉，请查看Spring。它提供了许多工具和技术来自动处理此类情况，并消除对大部分样板代码的需求。有关更多信息，请参阅依赖注入。

于 2012-03-17T12:34:58.723 回答
1

我已经看到一个 PHP 系统（Moodle）几乎完全使用这种模式并且它工作得很好。所发生的只是将 DB 类型指定为配置变量，并将具体的 DB 访问类实例化为全局 DB 管理器对象，提供外观方法，例如 get_records()，它返回行对象的标准化数组。你是否会称这个外观或适配器是有争议的，但这并不令人担心。

我会说按照你目前的计划去做。您似乎已经正确地解耦了这些层并理解了模式的目的。此外，您的低级（DB）和高级（应用程序控制器）组件都依赖于中间的单个 DB 外观接口的方式是依赖倒置的一个很好的例子，所以加分！:)

于 2012-03-17T12:22:35.880 回答
0

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

于 2012-03-17T12:09:59.600 回答