我刚刚开始使用Spring Boot，使用Spring Data JPA。当我从表生成模型时，我创建了一个模型存储库来扩展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。
因为所谓的"服务"类(使用 N 层体系结构"继承"(是业务逻辑"存在"的地方。最后，这取决于您的方法/设计指南，您希望管理交易，构建项目的方式等。
如果只需要调用数据库并返回该数据，则可以安全地跳过"服务"调用/类。另一方面，如果你在"现实生活中"做某事，你最终会经常使用这些"服务"类，因为大多数操作(阅读：业务逻辑(都会在那里，所以你会希望将所有行为隔离在一个地方——否则你会到处注入豆子而不遵循任何"项目组织"等。有时这有点乏味，但另一方面，你知道在需要更改某些东西时在哪里寻找。在大中型项目中，这非常重要;如果您有多个人修改相同的代码库，则更是如此。
提示：保持小班授课。在"服务"类上注入大量的 bean(存储库、服务等等(是糟糕的设计，可能会导致你陷入其他无意义。
最好将应用程序的功能分离到单独的类中。(见单一责任原则 https://en.wikipedia.org/wiki/Single_responsibility_principle(。
在这种情况下，我的意思是，如果您需要在控制器和对 JPA 存储库的调用之间执行一些更高级的业务逻辑，那么这应该包含在服务层中。这可以防止控制器类在只关注处理请求并将责任传递给服务层时被业务逻辑污染。
但是，如果您只是执行一些简单的 CRUD 操作，那么直接从控制器调用存储库是绝对可以的。因此，这取决于您的应用程序真正需要做什么！
无需使用服务即可查询数据。当您在应用程序的另一部分中需要相同的功能时，最好编写服务以防止代码重复。