如何分离存储库和服务层答案

【问题标题】：How to separate Repository and Service Layers如何分离存储库和服务层
【发布时间】：2013-07-16 08:52:01
【问题描述】：

Repository和Service应该如何分离？恕我直言客户端（例如控制器）应该主要使用服务层而不是存储库，因为它应该与持久性实现分开。 Single Repository 应该只提供一个实体的访问方法，而 Service 的方法能够提供更复杂的操作，包括使用多个 Repository。

但是如何处理丰富的存储库，它不仅提供 CRUD 方法，还提供更多方法，比如 Spring Data 中的 JPARepository？在这样的实现中，有很多可能的获取对象的方法，在 Service 中复制它们并不酷。

那么解决这个问题的方法是什么？

A.像这样的服务层中的重复方法

@Service
class XService{

   @Autowired
   private XRepository repository;

   public List<X> findAll(){
        return repository.findAll();
   }
}

B.只需在控制器中使用存储库（自动装配或服务中的访问方法）

C.还有什么好的方法吗？

【问题讨论】：

【解决方案1】：

服务应该实现（业务）逻辑，并可能根据该逻辑修改实体。如果您的服务层只是存储库的薄包装，即仅按照您的描述获取实体，那么您的设计有问题。

逻辑通常分布在整个控制器中。识别该逻辑，将其提取并封装在服务中，并通过编排适当的服务来限制控制器管理应用程序的流程。

【讨论】：

上面的服务只提供了一种包装repos方法的方法，因为它只是示例，我知道服务层应该负责业务逻辑，但我不知道如何处理这么简单方法 - 直接从存储库中使用它们或将它们包装在服务方法中。例如。让我们考虑一下仅将 List 放入模型的 Controller 方法 - 我们应该使用 Repository 还是将该方法包装在 Service 中？
我认为这取决于。如果您有一个健康的服务层，但只是其中一些简单的“直接访问”方法 - 就这样吧。我会让服务包装它（如果出现新要求，也可以轻松更改它）。另一方面，如果您的服务层被如此简单、愚蠢的包装器所支配，那么就会出现问题。一种方法就是我所描述的：充实服务层。或者，如果您的应用程序足够简单并且您不希望进行实质性更改，则可以摆脱这些“服务”并直接使用存储库。任何不平凡的软件都会在某种程度上违反设计原则。