8 -- 深入使用Spring -- 7...2 MVC框架与Spring整合的思考

　　　　　　8.7.2 MVC 框架与Spring整合的思考

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

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

　　　　　　　　在实际的应用中，很少见到采用上面的访问策略，因为这是一种非常差的策略。不这样做至少有如下三个原因：

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

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

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

　　　　　　　　答案是采用工厂模式，或者服务定位器模式。对于采用服务定位器模式，是远方访问的场景。在这种场景下，业务逻辑组件已经在某个容器中运行，并对外提供某种服务。控制器无须理会该业务逻辑组件的创建，直接调用该服务即可，但在调用之前，必须先找到该服务 ------ 这就是服务定位器的概念。经典的Java EE应用就是这种结构的应用。

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

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

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

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

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

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

啦啦啦