Spring架构增强MultiActionController(2)

2. MultiActionController的缺点

MultiActionController把相关的业务方法集中在一个类中进行处理，减少控制类的数量。方便于系统的维护，可以重用相关的逻辑代码，提高代码的重用，同时也减少bean的配置。有太多的bean配置可以说是Spring 的一个暇疵。Spring提供IOC,让我们灵活的控制bean的依赖。同时我们需要去维护太多的bean配置，Spring项目中很大程度上都在滥用xml 配置文件，这很不利于团队开发和系统的后期维护。MultiActionController也不例外。

2.1. multiActionController的配置相对复杂

MultiActionController需要注入一个MethodNameResolver对象，再通过MethodNameResolver的mappings属性来提供请求与方法之间的映射。这样的配置是复杂的和难以理解的。使用Spring框架的确很灵活，但是有时这种过分的灵活反而增加了系统的复杂度。

2.2. multiActionController配置涉及的bean过多

除了自身的bean定义外，还需要把所有的映射配置到一个UrlHandlerMapping中去。这样除了维护multiActionController的自身的bean定义外，还需要维护UrlHandlerMapping的定义。

笔者十分反对这种具有连带性的配置，一个bean的属性改变会造成对别一个bean属性的改变。这样增加了系统的复杂度，和维护成本。所以必须提供一种默认的实现，让bean之间的依赖，不要造成bean属性之间的依赖。MultiActionController在这方面表示得十分不好。

2.3. 数据绑定支持不好

SimpleFormController专门用来支持编辑和表单提效的，它支持数据绑定，在这方面做得很好。可以把jsp页面的字段值绑定为某一对象(Command)。可以自定义command的名称。虽然MultiActionController也支持数据绑定，但是它并不支持自定义command的名称。它默认的comamnd名称为”command”。这也是不便于维护的，对象应该有一个代表自身含义的名字。如果所有页面的绑定对象都以“command”作为名字，那将难以理解。MultiActionController支持数据绑定的方法参见上面例子的saveUser方法。

3. 理想的MultiActionController构想

一个理想的MultActionController应该配置简单明了，并且无需要在多个地方进行配置。

应该支持对绑定对象自定义名称。

class="com.prs.application.ehld.sample.web.controller.SampleMultiMethodController"> listUser edtiUser saveUser ref="com.prs.application.ehld.sample.biz.action.sampleAction">

上面是一个更让人能够理解的配置。

(1)把请求与具体方法之间的映射作为MultiActionController自身的一个属性“urlMethodmappings”。
(2)通过一个commandName属性，可以让用户自由决定绑定对象的名称。
(3)简化UrlHandlerMapping的关联配置。对MutilActionController的bean配置进行改动时，无再需要去关心SimpleUrlHandlerMapping的bean配置。

4. 增强的MultiActionController实现

上面提到理想MultiActionController的构想，有三点需要实现。现在来讨论实现它们。

4.1把请求与具体方法之间的映射作为MultActionController自身的一个属性

也就是说MultiActionController提供一个“urlMethodMapping”的属性来保存请求路径与对应方法之间的映射关系。

我们知道MultiActionController有一个methodNameResolver的属性，而请求路径与方法之间的对应映射关系是由一个MethodNameResolver 的bean来保存的。我们一般可以配置一个PropertiesMethodNameResolver来作默认实现。把请求路径与方法之间的映射关系保存在PropertiesMethodNameResolver中的“mapping”属性中。