spring-boot - 为什么我不应该在 Controller 类中调用多个服务?

我刚刚在

这里阅读了以下文章:https://stackoverflow.com/questions/29394109/what-is-the-best-approach-to-use-multiple-services-inside-a-resource-controller

和这里:< a z148>我可以在 Controller 类中拥有多个服务 - Spring MVC 吗?

文章说我不应该在 Controller 类中调用多个服务。我应该将所有服务封装在一个 Facade 类(Facade 模式)中。



那么为什么不应该在一个 Controller 类中调用多个服务呢?

我可以在一个服务类中调用多个服务吗?这是对的吗?

回答1

从技术上讲,没有什么可以阻止您从控制器调用多个服务,但这可能是一个糟糕的设计决策,主要是由于https://en.m.wikipedia.org/wiki/Single-responsibility_principle。粗略地说,这表明类应该有一个单一的责任和改变的理由,控制器是你的应用程序的接口,应该只关注它。任何需要导入多个服务的类都可能包含一些业务逻辑,并且该代码可能比控制器类更好地放置在单独的业务层类中。

如果您在控制器的每个方法中只使用一个服务,那么您可能应该将控制器拆分为更小的控制器,每个控制器都使用与每个控制器相关的服务。

回答2

传统上,当我们谈论 MVC 模式时,控制器的工作是处理业务逻辑。但是,当我们实际实现它时,控制器可能会以一些验证例程调用、设置模型属性和视图(在 Rest 控制器中不需要)等结束。

具有服务层和持久层的设计模式从将所有这些逻辑与表示层分离的相同需求演变而来。因此,相应的,所有的业务逻辑都应该放在服务层,持久化逻辑放在持久层。

在 Controller 中调用多个服务肯定是可以接受的,但是还有一些方面,例如

  • 可重用性:如果您在服务层使用 Facade 模式封装多个服务调用的逻辑,则可以增加在其他地方重用该代码的机会。使用 Controller 方法中的所有逻辑,您不能重用它。
  • 事务:当有事务时,要标记事务边界,更有意义的是把逻辑封装在服务层,将方法标记为@Transactional。您当然可以使用注解从控制器管理事务,但是要处理想要回滚事务但同时保存错误数据的场景,您必须以编程方式对其进行管理。

相似文章