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();
       }
    }

类似的东西，我只要@Autowired注入

userRepository

就可以直接从

userRepository

查询数据。

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

service

和

serviceImpl

。

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

您不必使用服务即可查询数据。当您在应用程序的其他部分需要相同的功能时，最好编写一个服务来防止代码重复。

Answer 4

正如所说的“依赖抽象，而不是具体”，使用接口类将为软件工程添加更好的方法：它将有助于SOLID的开放封闭原则，其中项目应该对扩展开放并接近修改。当我们有了接口后，我们今天就有了一个实现，我们可以在需要时添加另一个新的实现。