Spring Data JPA Repo，为什么需要接口服务和服务实现

Question

我刚开始Spring Boot使用Spring Data JPA。当我从表生成模型时，我创建了一个modelRepo，它扩展了JpaRepository<myModel, String>

public interface userRepository extends JpaRepository<User, String>{
}

然后可以从控制器轻松调用userRepository.findAll()以获取数据。

但是，当我看一些教程时，在调用findAll（）之前，它们还有几个步骤。看下面：

public interface userService{
Iterator findAll();

}

    public class userServiceImpl implements userService{
       @Autowired
       UserRepository userRepository
       @Override
       Iterator findAll(){
        return userRepository.findAll();
       }
    }

像这样的东西，userRepository只要@Autowired注入，我就可以直接查询数据userRepository。

在某些示例中，它们与上面的结构相同。谁能解释为什么我们需要service和serviceImpl调用数据之前。

Answer 1

因为所谓的“服务”类（N 层架构中的“继承”）是业务逻辑“存在”的地方。最后，这取决于您的方法/设计指南、您希望管理事务的方式、构建您的项目等。

如果您只需要调用数据库并返回该数据，则可以安全地跳过“服务”调用/类。另一方面，如果你在“现实生活中”做一些事情，你最终会大量使用这些“服务”类，因为大多数操作（阅读：业务逻辑）都在那里，所以你会想要将所有这些行为隔离在一个地方——否则你会在任何地方注入 bean，而不遵循任何“项目组织”等。有时这有点乏味，但另一方面，当您需要更改某些内容时，您知道在哪里寻找。在大中型项目中，这非常重要；如果您有几个人修改相同的代码库，则更是如此。

提示：保持小班授课。在“服务”类上注入大量 bean（存储库、服务等等）是糟糕的设计，可能会导致您陷入其他无意义的境地。

Answer 2

将应用程序的功能分离到单独的类中是一种很好的做法。（参见单一责任原则https://en.wikipedia.org/wiki/Single_responsibility_principle）。

在这种情况下，我的意思是，如果您需要在控制器和对 JPA 存储库的调用之间执行一些更高级的业务逻辑，那么这应该包含在服务层中。这可以防止您的控制器类在只关心处理请求并将责任传递给服务层时被业务逻辑污染。

但是，如果您只是在执行一些简单的 CRUD 操作，那么直接从控制器调用存储库绝对没问题。所以这取决于您的应用程序真正需要做什么！