DAO（数据访问对象）最佳实践 - 我看到的例子都使用了DAO和Services对象，这里的最佳实践是什么？

Question

我正在创建一个数据访问对象，以便从Google App Engine中检索构建在Spring框架上的Web应用程序的信息（第一次为所有人提供）。

我看到许多使用Controller / webapp的示例 - ＆gt;服务 - ＆gt; DAO - ＆gt; JDO / Google-app-engine模式。

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

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

有人能告诉我单独服务层的理性吗，随着项目变得越来越大而越复杂，这会变得明显吗？

Answer 1

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

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

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

Answer 2

是的，最初似乎服务层没有增加太多的等式。但想想就好。

服务层=您的演示文稿和业务层之间的一个层。

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

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

安全问题

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

如果要定义应用程序的各个层，还需要关注这些问题。