MVC框架与Spring整合的思考

对于一个基于B/S架构的JavaEE应用而言，用户请求总是向MVC框架的控制器请求，而当控制器拦截到用户请求后，必须调用业务逻辑组件来处理用户请求。此时有一个问题：控制器应该如何获得业务逻辑组件？

最容易想到的策略是，直接通过 new 关键字创建业务逻辑组件，然后调用业务逻辑组件的方法，根据业务逻辑方法的返回值确定结果。

在实际开发中，很少采用上面的策略，因为这是一种非常差的策略。原因有三：

① 控制器直接创建业务逻辑组件，导致控制器和业务逻辑组件的耦合降低到代码层次，不利于高层次解耦。

② 控制器不应该负责业务逻辑组件的创建，控制器只是业务逻辑组件的使用者，无须关心业务逻辑组件的实现。

③ 每次创建新的业务逻辑组件导致性能下降。

对于轻量级的JavaEE应用，工厂模式 则是更实际的策略。因为在轻量级JavaEE应用中，业务逻辑组件不是EJB，通常就是一个POJO，业务逻辑组件的生成通常应由工厂负责，而且工厂可以保证该组件的实例只有一个，这样就可以避免重复实例化造成的系统开销。

采用工厂模式，将控制器和业务逻辑组件的实现分离，从而提供更好的解耦。在采用工厂模式的访问策略中，所有的业务逻辑组件的创建由工厂负责，业务逻辑组件的运行也由工厂负责。控制器只需定位工厂实例即可。

如果系统采用 Spring框架，则Spring成为最大的工厂。Spring负责业务逻辑组件的创建和生成，并可管理业务逻辑组件的生命周期。可以如此理解：Spring是个性能非常优秀的工厂，可以生产出所有的实例，从业务逻辑组件，到持久层组件，甚至控制器组件。

现在的问题是：控制器如何访问到Spring容器中的业务逻辑组件呢？有两种策略：

① Spring容器负责管理控制器Action，并利用依赖注入为控制器注入业务逻辑组件。

② 利用Spring的自动装配，Action将会自动从Spring容器中获取所需的业务逻辑组件。