应该如何分离存储库和服务? IMHO客户端(例如Controller)应该主要使用服务层而不是存储库,因为它应该与持久性实现分开。单一存储库应提供仅访问一个实体的方法,而服务方法能够提供更复杂的操作,包括使用多个存储库。
但是如何处理丰富的存储库,它不仅提供了CRUD方法,还提供了更多,比如Spring Data的JPARepository?在这样的实现中,有很多可能的获取对象的方法,在Service中复制它们并不酷。
那么问题的解决方案是什么?
一个。像这样的服务层中的重复方法
@Service
class XService{
@Autowired
private XRepository repository;
public List<X> findAll(){
return repository.findAll();
}
}
B中。只需在控制器中使用存储库(自动装配或服务中的访问方法)
℃。还有其他好方法吗?
答案 0 :(得分:4)
服务应该实现(业务)逻辑,并可能根据该逻辑修改实体。如果您的服务层只是存储库的一个薄包装器,即只根据您的描述提示获取实体,那么您的设计就会出现问题。
逻辑通常遍布控制器。识别该逻辑,将其提取并封装在服务中,并通过编排适当的服务来限制控制器管理应用程序的流程。