我刚开始使用setContent(R.layout.**myModule)开始Spring Boot工作。当我从表生成模型时，我创建了一个扩展Spring Data JPA
JpaRepository<myModel, String>然后，从控制器，我可以轻松调用public interface userRepository extends JpaRepository<User, String>{
}
来获取数据。
然而，当我查看一些教程时，他们在调用findAll（）之前还有几个步骤。看看下面：
userRepository.findAll()}
public interface userService{
Iterator findAll();
这样的事情，我可以直接从 public class userServiceImpl implements userService{
@Autowired
UserRepository userRepository
@Override
Iterator findAll(){
return userRepository.findAll();
}
}
查询数据，只要@Autowired注入userRepository。
在某些例子中，它们在上面做了相同的结构。任何人都可以在调用数据之前解释为什么我们需要userRepository和service。
答案 0 :(得分：3)
因为所谓的＆＃34;服务＆＃34;类（＆＃34;继承＆＃34;具有N层架构）是业务逻辑和生活的地方。最后，它取决于您的方法/设计指南，您希望管理事务的方式，构建项目等等。
如果您只需要调用数据库并返回该数据，则可以安全地跳过＆＃34;服务＆＃34;呼叫/班。另一方面，如果你在现实生活中做了一些事情，你将最终使用那些＆＃34;服务＆＃34;因为大多数操作（读取：业务逻辑）将会存在，所以你会希望将所有这些行为隔离在一个地方 - 否则你会在任何地方注入bean而不遵循任何＆＃34;项目组织＆＃34;除其他事项外。有时它有点单调乏味，但另一方面，无论何时需要改变某些东西，你都知道在哪里寻找。在大中型项目中，这非常重要;如果你有几个人修改相同的代码库，那就更多了。
提示：让您的课程变小。在＆＃34;服务＆＃34;上注入大量的豆子（存储库，服务和什么不是）阶级是糟糕的设计，可能会导致你的其他非感官。
答案 1 :(得分：3)
将应用程序的功能分离到单独的类中是一种很好的做法。 （参见单一责任原则https://en.wikipedia.org/wiki/Single_responsibility_principle）。
在这种情况下，我的意思是，如果您需要在控制器和对JPA存储库的调用之间执行一些更高级的业务逻辑，那么这应该包含在服务层中。这可以防止您的控制器类被业务逻辑污染，只需要处理请求并将责任传递给服务层。
但是，如果您只是进行一些简单的CRUD操作，那么直接从您的控制器调用存储库绝对没问题。所以这取决于你的应用程序需要做什么！
答案 2 :(得分：1)
您不必使用服务即可查询数据。当您在应用程序的另一部分需要相同的功能时，编写服务以防止代码重复是一种更好的做法。