DAO（数据访问对象）最佳实践 - 我看到的示例同时使用 DAO 和服务对象，这里的最佳实践是啥？

Posted 2023-04-18

【中文标题】DAO（数据访问对象）最佳实践 - 我看到的示例同时使用 DAO 和服务对象，这里的最佳实践是啥？

【英文标题】：DAO (data access object) best practices - examples I see use a DAO and a Services object both, what is the best practice here?DAO（数据访问对象）最佳实践 - 我看到的示例同时使用 DAO 和服务对象，这里的最佳实践是什么？

【发布时间】：2011-04-26 05:40:39

【问题描述】：

我正在创建一个数据访问对象，以从 Google App Engine 中检索基于 Spring 框架构建的网络应用程序的信息（这是第一次）。

我看到许多使用 Controller/webapp -> Service -> DAO -> JDO/Google-app-engine 模式的示例。

在此模式中，DAO 层是唯一了解 JDO 的层，因此如果数据存储发生更改，则该层是唯一需要替换的层。服务层调用 DAO 层并格式化/操作所需的数据。

我的问题是为什么需要额外的服务层？至少最初看起来服务层并没有给等式增加太多。我自然会想到只写一个 DAO 层来封装 JDO 请求并操作和返回数据。

谁能告诉我单独服务层的合理性，随着项目变得更大和更复杂，这会变得显而易见吗？

【参考方案1】：

通常您将 DAO 放在服务层中，因为随着您的应用程序变得越来越复杂，您将在服务中做有用且重要的事情。例如，您可能会使用 1 个以上的 DAO 来协调复杂的数据操作。服务层还提供划分横切关注点的 API 边界，例如事务管理、授权检查、性能日志记录等。

将功能抽象为服务的另一个好处是它促进了可重用和可维护的组件。开始时，您可能只对展示一些 html 感兴趣。您编写一个加载一些数据的服务，并在服务层（表示层）之上的层中处理 html 部分。现在你想建立一个 RESTful web 服务。您的服务层可以重复使用来加载数据；您只需要担心 Web 服务端点返回的 json 或 xml（当然还有 REST 语义）。

因此，对于简单的情况，Service 层可能会增加很少的内容，但随着您的应用程序的扩展，它们变得有价值，甚至对于保持代码的简洁至关重要。

【参考方案2】：

是的，最初似乎服务层并没有给等式增加太多。但是这样想吧。

服务层 = 表示层和业务层之间的层。

您一定已经意识到，在层之间分离关注点总是好的。您的服务层可以映射到不同的业务领域、表示层，而无需担心 DOA 层的使用方式。

您可以将其视为其他两个层之间的边界，在本例中是表示层和业务层之间的边界。表示层中的代码通常实现用例。典型的用例是用户执行的一系列操作，这些操作导致一个或多个业务对象、工作流和服务之间的交互。服务层允许您使用中间 API 抽象这些较小的交互，通过更粗粒度的服务公开。表示层对层中的一项服务进行一次调用。调用的服务层方法将协调业务层中的对象和工作流以实现所需的行为。

安全问题

我确实围绕服务堆栈创建了一个安全层。这将帮助我识别用户的真实性并访问给定的服务。 我还围绕服务层定义了一个事务层，它告诉数据库引擎提交在服务层所做的更改，一旦它在成功执行后返回。

如果您要定义应用程序的层，也需要关注这些事情。