DAO 层应该如何实现？一张表 DAO 还是多表 DAO？

Question

我正在按照分层架构实现一个模块。它将具有表示层、服务层、业务层和 DAO 层。 根据分层架构指南，通信流应该是自上而下的。同样，依赖关系也应该是自上而下的，即表示层 - 使用 -> 服务层 - 使用 -> 业务层 - 使用 -> DAO 层。即业务层不应该依赖于服务层等等。

问题一：

每一层的输入应该是什么？既然服务层是从表示层调用的，那么服务层应该接受 UI bean 作为输入吗？或 Service Bean 作为输入？ 业务层和 DAO 层也是如此。

问题2：

DAO 层应该是每个表还是可以处理多个表（全部由单个模块拥有）？我模块的数据存储在多个表中。由于所有这些表都归一个模块所有，我认为有一个单一的 DAO 层是有意义的，它从上层抽象了数据的多表存储。此外，如果需要插入 DAO 层的不同实现（数据库存储、SVN 存储等），则插入单个实现（处理所有数据）是有意义的。此外，多表 DAO 在获取数据方面会提高性能（单个连接查询就足够了）

问题 3：

如果考虑多表 DAO 设计，那么 DAO 层的输入将是业务 bean。 DAO 层负责将业务 bean 转换为多个 DB bean，每个 DB bean 代表一个表并处理持久性。 但这不符合分层架构，它说层应该是隔离的，任何层都不应该依赖于它的上层。在这种情况下，DAO 层的输入是业务 bean（不是 DB bean），从业务 bean 到 DB bean 的转换，反之亦然是 DAO 层的责任，这意味着它知道如何将业务 bean 转换为 DB bean反之亦然。

有人可以澄清一下吗？实现这样一个模块的正确方法应该是什么？当前的实施是否符合指导方针？ 一个适当的解释会有很大帮助。谢谢！

我目前的实现是

• 表示层： 将 UI bean 转换为服务 bean 并将其传递给服务层。

• 服务层： 将服务 bean 转换为业务 bean 并将其传递给业务层。还协调各种依赖服务之间的调用。处理事务边界。将服务 bean 返回到表示层。

• 业务层： 将业务 bean 传递给 DAO 层。将服务 bean 返回到服务层

• DAO 层： 将业务 bean 转换为 DB bean，反之亦然。将业务 bean 返回到业务层。

Answer 1

我将在整个答案中使用社交网络网站的示例。

1. 您的 UI 应该依赖于您的服务，但只能是单向的。想象一下当您在 UI 上有一些帖子并且您打算实现“Like”功能的情况。直观地说，当用户单击帖子的“赞”按钮时，应在相应表中创建一条记录，然后在 UI 上显示。因此，您需要实现一个 Like 功能，这在 UI 上意味着您有一个 POST 请求处理程序，该处理程序调用服务层中的相应方法，传递用户 ID 和帖子 ID。服务层应该对 UI 完全不可知，并且应该只处理会话验证并调用业务层中的相应方法。您的业​​务层应该依次处理您的操作逻辑并确保调用 DAO 层中的方法，因此在数据库中创建了 Like 记录，并且可能会发生您可能需要的其他一些事情。当所有要调用的 DAO 方法都成功执行（如果没有，则必须正确处理错误），业务层应响应服务层，然后将电子邮件发送给用户以进行通知并响应 UI。

2. 小心被称为“过早优化”的龙。你应该有一个单一的 DAO 层，因为它会大大简化你的生活。如果稍后您遇到一些性能问题，那么您将不得不解决它们。但是，如果您将遇到性能问题，则很可能是由其他原因引起的。 DAO 层意味着您有一个代表您的 DAO 的层。

3. 参见第 2 点。