在spring mvc控制器中使用Services和DAO
我正在构建一个Web应用程序，主要构成来自后端/数据库的数据的CRUD操作。 在某些情况下，我必须编写业务逻辑（我确信随着我们深入开发，我们将构建更多业务逻辑）。 目前，我创建的每个UI屏幕都创建了一个模型类，Service类，DAO类，一个控制器（本质上是它的servlet）和一堆jsp页面。 在大多数情况下，服务类只是从DAO调用方法来传递模型对象。 基本上我们使用模型类来映射UI屏幕中的数据。 因此，控制器将在提交表单时填充模型对象。 我已经开始使用服务类来保持从Web层到DAO层的分离层。 但有时我觉得服务类只是添加不必要的API调用级别，我认为我可以将DAO注入Controller并更快地完成任务。 我想仅在需要执行其他业务逻辑时才使用服务类。 如果你必须设计一个应用程序，你考虑使用控制器 – > DAO vs controller-> Service-> DAO控制流程？
DAO更精细，可以处理一个特定的实体。 服务提供宏级function，最终可能使用多个DAO。 通常，服务用于定义事务边界以获得primefaces性。 换句话说，如果您最终使用多个DAO更新多个表，则在服务时定义事务边界将有助于提交或回滚对DB执行的所有更改。
在您的设计中，由于您主要为各种实体进行CRUD，因此服务似乎没有增加太多价值。 但是，将基于Web的前端视为更新数据的一种方式。 使用服务将允许您稍后将其与Web服务相同的function暴露给其他forms的客户端，如第三方集成商等。
总而言之，您的设计似乎与传统做法一致。 如果您认为可以基于某些常见主题将多个服务组合成一个，以便它可以减少代码的开销，那么，您应该继续执行它。 在一天结束时，最终目标是创建可维护的代码，在需要时没有人害怕改变。
在Pro-Spring-3中，他们提到了下面的行，用于JPA2的控制器
Once the EntityManagerFactory had been properly configured, injecting it into your service layer classes is very simple.
他们使用与服务和存储库相同的类，如下所示：
package com.apress.prospring3.ch10.service.jpa; // Import statements omitted @Service("jpaContactService") @Repository @Transactional public class ContactServiceImpl implements ContactService { private Log log = LogFactory.getLog(ContactServiceImpl.class); @PersistenceContext private EntityManager em; // Other code omitted }
但是如果您要使用spring-data CRUDRepository或JPARepository，那么您的DAO将是Interface，您必须创建服务层来处理您的代码
我在这里引用我的答案
它的优缺点是使用服务层的优势是，如果你想对Spring Security和角色等做任何事情，它可以让你在未来移动它。它允许你更primefaces地处理事务，Spring本身就是真的很好的注释。
处理多个聚合根时使用服务类。
注入存储库（也就是返回集合的dao）或dao直接进入控制器，不需要额外的层/类来进行基本获取。
仅在必要时使用服务类，否则您需要两倍的代码。
您可以使存储库通用，并使用@Transactional(propagation = Propagation.REQUIRED)来强制执行事务，但如果已存在则不会创建新事务。 因此，如果您稍后在一个服务类方法中使用多个repositoes，则只有一个事务。