基于 B/S 架构的 JavaEE 应用中，用户向 MVC 框架的控制器请求，控制器拦截到用户请求后，调用业务处理用户请求。控制器应该如何获得业务逻辑组件？
答案是采用工厂模式，或者服务定位模式，对于采用服务定位器模式，是远程访问的场景。在这种场景下，业务逻辑组件已经在某个容器中运行，并对外提供某种服务。控制器无须理会该业务逻辑的创建，直接调用该服务即可，但在调用之前，必须先找到该服务——这就是服务定位器的概念。经典 JavaEE 应用就是这种结构的应用。
对于轻量级的 JavaEE 应用，工厂模式则是更实际的策略。因为在轻量级 JavaEE 应用中，业务逻辑是 EJB ，通常就是一个 POJO ，业务逻辑组件的生成通常应由工厂负责，而且工厂可以保证该组件的实例只需一个就够了，可以避免重复实例化造成的系统开销。
采用工厂模式，将控制器与业务逻辑组件的实现分离，从而提供更好的解耦。在采用工厂模式的访问策略中，所有的业务逻辑组件的创建由工厂负责，业务逻辑组件的运行也由工厂负责。而控制器只需定位工厂实例即可。
如果系统采用 Spring 框架，则 Spring 成为最大的工厂。Spring 负责业务逻辑组件的创建和生成，并可管理业务逻辑组件的生命周期。可以如此理解：Spring 是个性能非常优秀的工厂，可以生产出所有的实例，从业务逻辑组件，到持久层组件，甚至控制器组件。
那么，控制器如何访问到 Spring 容器中的业务逻辑组件呢？为了让 Action 访问 Spring 的业务逻辑组件，有两种策略：
- Spring 容器负责管理控制器 Action ，并利用依赖注入为控制器注入业务逻辑组件（这种方式可以充分利用 Spring 的 IoC 特性，但需要将配置 Struts2 的控制器即 Action 部署在 Spring 容器中，而 struts.xml 文件中还需要配置一个“伪 Action ”，因此导致配置文件冗余;并且Action 的业务逻辑组件接收容器的注入，将导致代码的可读性降低）。
- 利用 Spring 的自动装配，Action 将会自动从 Spring 容器中获取所需的业务逻辑组件。