我正在创建一个数据访问对象，以便从 Google App Engine 检索基于 Spring 框架构建的 Web 应用程序的信息（这还是第一次）。
我看到许多使用 Controller/webapp 的示例 ->服务-> DAO-> JDO/Google 应用程序引擎模式。
在此模式中，DAO 层是唯一了解 JDO 的层，因此，如果数据存储发生更改，则该层是唯一需要替换的层。服务层调用 DAO 层并格式化/操作所需的数据。
我的问题是为什么需要额外的服务层？至少一开始，服务层似乎并没有给这个等式增加太多。我自然会想到只写一个DAO层来封装JDO请求并操作和返回数据。
有人可以告诉我单独的服务层的合理性吗？随着项目变得更大、更复杂，这会变得明显吗？
I'm creating a data access object to retrieve information from Google App Engine for a web app built on the Spring framework (first time for all).
I see a number of examples that use a Controller/webapp -> Service -> DAO -> JDO/Google-app-engine pattern.
In this pattern the DAO layer is the only one that knows about JDO, thus this layer is the only one needing replacement if the data store changed. The Services layer calls the DAO layer and formats/manipulates the data s needed.
My question is why the extra Service layer? At least initially it doesn't seem like the Service layer is adding much to the equation. I would naturally think to just write a DAO layer to encapsulate the JDO requests and manipulate and return the data.
Can someone show me the rational for a separate Service layer, will this become obvious as the project becomes larges and more complex?
发布评论
评论（2）
通常，您将 DAO 放在服务层中，因为随着您的应用程序变得越来越复杂，您将在服务中执行有用且重要的事情。例如，您可能需要使用多个 DAO 来协调复杂的数据操作。服务层还提供 API 边界来划分横切关注点，例如事务管理、授权检查、性能日志记录等。
将功能抽象到服务中的另一个好处是它可以促进可重用和可维护的组件。当您开始时，您可能只对呈现一些 html 感兴趣。您编写一个加载一些数据的服务，并在服务层（表示层）之上的层中处理 html 部分。现在您想要建立一个 RESTful Web 服务。您的服务层可以被重用来加载数据；您只需担心 Web 服务端点返回的 json 或 xml（当然还有 REST 语义）。
因此，对于简单的情况，服务层可能会增加很少的内容，但随着应用程序的扩展，它们变得有价值，甚至对于保持代码整洁至关重要。
Typically you put DAOs in a service layer because as your app gets more complicated, you will do useful and non trivial things in the service. For example, you might coordinate complicated data operations with more than 1 DAO. Service layers also provide API boundaries that demarcate cross cutting concerns, like transaction management, authorization checks, performance logging, etc.
Another reason its good to abstract your functionality into services is that it promotes reusable and maintainable components. When you start, you might be interested in just presenting some html. You write a service that loads some data, and handle the html part in the layer above the service layer (presentation layer). Now you want to stand up a RESTful webservice. Your service layer can be reused to load the data; all you have to worry about is the json or xml your webservice endpoint returns (and of course the REST semantics).
So, for simple cases the Service layer might add little, but as your app expands they become worthwhile and even essential to keeping the code clean.
是的，最初看起来服务层并没有增加太多。但这样想一下。
服务层 = 表示层和业务层之间的层。
您一定已经意识到，层与层之间的关注点分离总是好的。您的服务层可以映射到不同的业务域、表示层，而不必担心 DOA 层的使用方式。
您可以将其视为其他两个层之间的边界，在本例中是表示层和业务层之间的边界。表示层中的代码通常实现用例。典型的用例是用户执行的一系列操作，这些操作导致一个或多个业务对象、工作流和服务之间的交互。服务层允许您使用中间 API 抽象这些较小的交互，并通过更粗粒度的服务公开。表示层对该层中的一项服务进行一次调用。被调用的服务层方法将协调业务层中的对象和工作流以实现所需的行为。
安全问题
如果您正在定义应用程序的层，这些事情也需要关注。
Yes, Initially it seems like the service layer does not adding much to the equation. But think about it like this.
Service Layer = a layer between your presentation and business layer.
You must have been aware that it is always good to have separation of concern between layers. Your service layer can map to distinct business domain, presentation layers, without being bothered of how your DOA layer is used.
You can think of this as boundary between two other layers, in this case between the presentation and business layers. The code in the presentation layer typically implements use cases. A typical use case is a sequence of actions performed by the user that result in interactions between one or more business objects, work flows, and services. The service layer allows you to abstract these smaller interactions with an intermediate API, exposed through more coarsely granular services. The presentation layer makes one call to one service in the layer. The invoked service layer method will coordinate the objects and work flows in the business layer to implement the required behavior.
Security Concerns
These things are also need to be in concern, if you are defining layers of your application.