是什么让 Struts 紧耦合

What makes Struts tightly coupled

一段时间以来,我一直在努力寻找这个问题的明确答案,但一直没有成功。我需要知道为什么 Struts 是紧密耦合的? struts 的哪个组件使其紧密耦合。

正如这位伟大的 Mkyong article 所讨论的那样,使 Struts 紧密耦合的不是某些东西的 存在 ,而是 不存在 的东西。 Struts 基本上是一个 web UI 框架,可以与 Spring MVC 相提并论。然而,与 Spring 不同的是,Struts 没有开箱即用的依赖注入支持。因此,这意味着当使用 Struts 时,如果给定的依赖关系发生变化,则可能必须更改整个代码。换句话说,您在 Struts 中使用的组件与框架紧密耦合。

这个问题有两种看法:

  1. Struts 1 本身是tightly-coupled,而
  2. Struts 1 是 tightly-coupled servlet 规范

第 1 期

消除这个很简单;使用 Spring 的受支持版本,并且您在 application 级别拥有所需的所有 DI,例如,您可以注入您的服务,使用 AOP 连接等

框架 级别,您没有相同的灵活性。您不能随意更换 Struts1 框架组件。这就是为什么当需要 framework-level 功能时,自定义请求处理器和操作基础 类 是第一种方法——没有其他地方可以放置它。

第 2 期

消除问题 #2 并不那么简单:Struts 工件所有参考 servlet 规范工件,如 HTTP 请求和响应。如果您想将其抽象化,例如为了更容易测试或业务逻辑重用,您必须手动进行。

一个示例是将请求参数(例如,表单值)编组到域 object 或简单映射中,然后将其传递给您的域逻辑。

Struts 1 是在 DI/IoC 之前写的,这是酷孩子们正在做的事情,在严格的层隔离很常见之前,等等。它写在 early .多年来它一直带着这个包袱,因为向后兼容是一回事。

您可能会争论与 servlet 规范的耦合是好是坏:这实际上是业务逻辑和 Web 应用程序之间的隔离发生在何处、谁对此负责以及您希望如何测试的问题它。

Unit-testing Struts 1 个动作有点像 PITA。如果它所做的只是处理 web-app-to-business-logic 编组,那么它是有争议的,他们不需要 进行单元测试:业务逻辑需要,但是 Struts 1 层可以通过网络应用程序级别的集成测试进行测试。 (我认为这甚至是有道理的,我对 Struts 2 动作测试也有同样的感觉——但是 S2 动作很容易测试(除了大量的拦截器交互和其他一些 less-common 东西) 区别不太重要。