spring 为什么要使用服务层？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/3688664/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Why use service layer?
提问by joe martinez
I looked at the example on http://solitarygeek.com/java/developing-a-simple-java-application-with-spring/comment-page-1#comment-1639
我查看了http://solitarygeek.com/java/developing-a-simple-java-application-with-spring/comment-page-1#comment-1639上的示例
I'm trying to figure out why the service layer is needed in the first place in the example he provides. If you took it out, then in your client, you could just do:
我试图弄清楚为什么在他提供的示例中首先需要服务层。如果你把它拿出来，那么在你的客户端，你可以这样做：
UserDao userDao = new UserDaoImpl();
Iterator users = userDao.getUsers();
while (…) {
…
}
It seems like the service layer is simply a wrapper around the DAO. Can someone give me a case where things could get messy if the service layer were removed? I just don't see the point in having the service layer to begin with.
似乎服务层只是围绕 DAO 的一个包装器。有人可以给我一个案例，如果删除服务层，事情会变得混乱吗？我只是没有看到让服务层开始的意义。
回答by Nathan Hughes
Having the service layer be a wrapper around the DAO is a common anti-pattern. In the example you give it is certainly not very useful. Using a service layer means you get several benefits:
让服务层成为 DAO 的包装器是一种常见的反模式。在您给出的示例中，它肯定不是很有用。使用服务层意味着您可以获得多项好处：
you get to make a clear distinction between web type activity best done in the controller and generic business logic that is not web-related. You can test service-related business logic separately from controller logic.
you get to specify transaction behavior so if you have calls to multiple data access objects you can specify that they occur within the same transaction. In your example there's an initial call to a dao followed by a loop, which could presumably contain more dao calls. Keeping those calls within one transaction means that the database does less work (it doesn't have to create a new transaction for every call to a Dao) but more importantly it means the data retrieved is going to be more consistent.
you can nest services so that if one has different transactional behavior (requires its own transaction) you can enforce that.
you can use the postCommit interceptor to do notification stuff like sending emails, so that doesn't junk up the controller.
您可以明确区分最好在控制器中完成的 Web 类型活动和与 Web 无关的通用业务逻辑。您可以将与服务相关的业务逻辑与控制器逻辑分开测试。
您可以指定事务行为，因此如果您调用多个数据访问对象，您可以指定它们发生在同一事务中。在您的示例中，有一个对 dao 的初始调用，然后是一个循环，其中可能包含更多的 dao 调用。将这些调用保留在一个事务中意味着数据库所做的工作更少（它不必为每次调用 Dao 都创建一个新事务），但更重要的是，这意味着检索到的数据将更加一致。
您可以嵌套服务，以便如果一个服务具有不同的事务行为（需要自己的事务），您可以强制执行该行为。
你可以使用 postCommit 拦截器来做通知的事情，比如发送电子邮件，这样就不会破坏控制器。
Typically I have services that encompass use cases for a single type of user, each method on the service is a single action (work to be done in a single request-response cycle) that that user would be performing, and unlike your example there is typically more than a simple data access object call going on in there.
通常，我的服务包含单一类型用户的用例，服务上的每个方法都是该用户将执行的单个操作（在单个请求-响应周期中完成的工作），与您的示例不同的是通常不仅仅是在那里进行的简单数据访问对象调用。
回答by Jon
Take a look at the following article:
看看下面的文章：
http://www.martinfowler.com/bliki/AnemicDomainModel.html
http://www.martinfowler.com/bliki/AnemicDomainModel.html
It all depends on where you want to put your logic - in your services or your domain objects.
这一切都取决于您要将逻辑放置在何处 - 在您的服务或域对象中。
The service layer approach is appropriate if you have a complex architecture and require different interfaces to your DAO's and data. It's also good to provide course grained methods for clients to call - which call out to multiple DAO's to get data.
如果您具有复杂的体系结构并且需要不同的 DAO 和数据接口，则服务层方法是合适的。为客户端调用提供课程粒度的方法也很好 - 调用多个 DAO 来获取数据。
However, in most cases what you want is a simple architecture so skip the service layer and look at a domain model approach. Domain Driven Design by Eric Evans and the InfoQ article here expand on this:
然而，在大多数情况下，您想要的是一个简单的架构，因此跳过服务层并查看域模型方法。Eric Evans 的领域驱动设计和这里的 InfoQ 文章对此进行了扩展：
回答by James Selvakumar
Using service layer is a well accepted design pattern in the java community. Yes, you could straightaway use the dao implementation but what if you want to apply some business rules.
使用服务层是 Java 社区公认的设计模式。是的，您可以直接使用 dao 实现，但是如果您想应用一些业务规则怎么办。
Say, you want to perform some checks before allowing a user to login into the system. Where would you put those logics? Also, service layer is the place for transaction demarcation.
比如说，您希望在允许用户登录系统之前执行一些检查。你会把这些逻辑放在哪里？此外，服务层是事务划分的地方。
It's generally good to keep your dao layer clean and lean. I suggest you read the article “Don't repeat the DAO”. If you follow the principles in that article, you won't be writing any implementation for your daos.
保持你的 dao 层清洁和精简通常是好的。我建议你阅读文章“不要重复 DAO”。如果你遵循那篇文章中的原则，你就不会为你的 daos 编写任何实现。
Also, kindly notice that the scope of that blog post was to help beginners in Spring. Spring is so powerful, that you can bend it to suit your needs with powerful concepts like aop etc.
另外，请注意该博客文章的范围是帮助 Spring 的初学者。Spring 非常强大，您可以使用 aop 等强大的概念来弯曲它以满足您的需求。
Regards, James
问候， 詹姆斯
