为什么我应该在控制器类中调用多个服务？
我刚刚阅读了下面的文章
这里：什么是最好的在资源控制器中使用多个服务的方法？
在这里：我可以在一个中拥有多个服务控制器类 - 春季MVC？
文章说，我不应该在控制器类中调用多个服务。我应该将所有服务封装在立面类（立面模式）中。
那么，为什么我不应该在控制器类中调用多个服务呢？
我可以在服务类中调用多个服务吗？正确吗？
I've just read the articles below
here: What is the best approach to use multiple services inside a resource controller?
and here: Can I have multiple services in a Controller class - Spring MVC?
the article said that I shouldn't call multiple services in a Controller class. I should encapsulate all services in a Facade class (Facade pattern).
So Why shouldn't I call multiple services in a Controller class?
And Can I call multiple service in a Service class? Is it correct?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
从技术上讲，没有什么可以阻止您从控制器调用多个服务，但这可能是一个不好的设计决定，主要是由于单一责任原则。这大致决定了类应该具有更改的责任和理由，控制器是您应用程序的界面，并且应该专注于此。任何需要导入多个服务的类都可能包含某些业务逻辑，并且该代码可能比控制器类更好地放置在单独的业务层类别中。
如果您仅在控制器的每个Metod中使用单个服务，则可能应该将控制器分为较小的控制器，每个控制器使用每个服务，而每个服务器都使用与每个控制器相关的服务。
Technically there is nothing that prevents you from calling multiple services from your controller, but it is probably a bad design decision, mainly due to the Single Responsibility Principle. Roughly this dictates that classes should have a single responsibility and reason to change, controllers are the interface of your application and should focus on being only that. Any class that needs to import multiple services probably contain some business logic and that code is probably better placed in separate business layer classes than the controller class.
If you only use a single service in each metod of your controller maybe you should split the controller into smaller controllers that each use the service that is relevant for each of them.
传统上，当我们谈论MVC模式时，控制器的工作是照顾业务逻辑。但是，当我们实际实施它时，控制器可能最终会带有一些验证例程调用，设置模型属性和视图（在REST控制器中不需要）等。
具有服务层和持久性层从同一的设计模式需要将所有这些逻辑与演示层分开。因此，因此，所有业务逻辑均应在服务层和持久性层面上进行。
在控制器中对多个服务的呼叫绝对是可以接受的，但是有一些方面，例如
@transactional。您当然可以使用注释来管理控制器的事务，但是要处理类似于回滚事务的方案，但同时保存错误数据，您将必须以编程方式管理它。Traditionally, when we talk about MVC pattern, the job of the controller is to take care of the Business Logic. However, when we actually implement it, the controller may end up with some validation routine calls, setting model attributes and view (not required in Rest controller) etc.
The design pattern to have Service layer and persistence layer evolved from the same need to separate all this logic from presentation layer. So, accordingly, all the business logic shall go in Service layer and persistence logic in persistence layer.
Calls to multiple services in Controller is definitely acceptable but then there are aspects like
@Transactional. You can certainly manage Transaction from Controller using annotation but then to handle scenarios like you want to rollback the transaction but at the same time Save the error data, you will have to manage it programmatically.