我目前正在学习Spring Boot，并且我已经看到人们如何创建控制器，注入服务类以及在服务类中注入存储库。
为什么我们需要服务类作为中间人？为什么我们不能将存储库注入控制器？
这是让我感到困惑的教程：https://www.youtube.com/watch?v=lpcOSXWPXTk&list=PLqq-6Pq4lTTbx8p2oCgcAQGQyqN8XeA1x
答案 0 :(得分：6)
您并不总是需要服务层。特别是如果您的API只是简单的CRUD操作，例如，没有真正的逻辑或计算。
但是，如果您有一个在查询存储库之前执行某些逻辑的API，那么这应该位于单独的服务类中。这是所谓的单一责任原则所带来的良好做法。
https://en.wikipedia.org/wiki/Single_responsibility_principle
答案 1 :(得分：3)
分层体系结构通常得到这种争论的支持：
我们使用图层来允许我们抽象出底层实现，以便我们可以轻松地改变它。
分层的一个令人愉快的副作用是 - 如果忠实地遵循 - 它可以通过（a）使用接口来定义每一层和（b）鼓励关注点分离来使系统更易于测试。
所以，这就是原则（简要地说，至少），但就像任何原则一样，它可能会被误解和误用。
虽然在大多数情况下，从视图层隐藏数据访问的分层（反之亦然）的好处是可靠的，但在视图层和数据层之间包含服务层的好处是并不总是如此引人注目。一个有......的系统。
...可能不需要服务层。
然而，有一个系统......
......可能确实需要一个服务层。
答案 2 :(得分：-1)
这是一种将服务功能与传输分开的方法，您的服务定义了涵盖单一责任（SOLID）的功能，并且可以使用不同的端口（六边形体系结构）公开，例如HTTP / REST或AMQP。
添加服务层使您可以灵活地在将来更改端口，或使用多个端口。
答案 3 :(得分：-1)
Spring启动控制器是外部世界的接口，例如与UI没有太大区别。 就像您希望能够拥有多种UI风格一样，您可以使用多个业务逻辑接口。特别是如果您希望它能够长久存在并适应未来的API框架。 如果您的逻辑嵌入在控制器中，那么当您到达那一点时，您必须进行一些重构。
因此需要单独的控制器取决于逻辑的复杂性。
答案 4 :(得分：-1)
就像这样，因此您不必在RestController层中放入很多代码，这些代码应该是干净的，并且仅包含与通信相关的代码。
因此所有逻辑和IF等都应保留在Controller层中。
Repository层应坚持 interface 的方式，该方法内部不应包含任何代码，而应仅包含如何获取数据的布局，而不应包含其逻辑。