[SpringMVC]修改源码使之能够更加智能的自动装配request请求参数.

Spring MVC做些类似WebApi的东西还是不错， 其实硬要那样做可以在前端做下动作。把那些表单的都转化成json之后再在controller里面获取对象。

SpringMVC的开闭原则，并非希望你通过直接修改源码的方式来修改，而是通过配置接口的实现类来实现customize，所以直接改源码的做法不是很妥当。比如说，你的改动在SpringMVC3.1的版本中，就很难被支持。难道你每次升级都重新去修改源码？

SpringMVC在进行参数映射时无法对应于多个POJO是一个老问题了，楼主的方法是一个比较好的尝试，不过也仅仅解决了部分问题，对于List、Map之类的映射，即使通过楼主的方法似乎也无法得到解决。楼主方法的致命问题在于不依赖Annotation的情况下，必须借助编译器把参数名称一起加入到编译的选项中去。

要彻底让SpringMVC的参数映射与Struts2类似的映射方式，最好的改造方式是引入SpringEL。不过这个改动稍微有点大，所以这也是SpringMVC迟迟没有加入这一特性的原因。

幸亏我当时没有盲目跟风!!!

开发环境一般都是编译的时候带上带上参数名称的。还有其他的实现机制吗？谁能分享一下 。

对，我认为Spring就是因为这个原因而没有采取对应多个pojo的策略
我这样修改源码主要是因为我只是希望在自己的项目中使用SpringMVC更加方便，当然没有考虑通用性喽

spring 这点弱爆了,难道他们认为一个表单就该对应一个po!!!!!

你应该反过来想，你在一个应用中，到底有多少情况会碰到一个表单对应于多个object？

首先，一个表单对应多个对象的情况不是很多，
另外，偶尔碰到这种情况，定义一个简单form类不就行了，何必去动源码那么麻烦。
class Form{
   A a;
   B b;
}
表单提交参数名用a.name,b.name;

另外，我认为在web层适当的定义一些Form类是有必要的，毕竟实际情况中，很多实体类并不能很好的映射到表单上，而且实体类的修改会涉及到页面表单字段的修改是个问题。

Struts2没有这个问题是因为Action本身就是Form Bean，这个看似简化代码的设计会造成Action属性混乱不可读，Action方法无法快速准确知道对应form的字段，维护麻烦等等问题。

我在想首页的改变是不是就是为了使javaeye和csdn更好的合并,而不是为了方便大家讨论呢?

我感觉这个本质的问题还是springMVC和struts2设计理念不同造成的，大家大部分人都是先接触struts2
而struts2的controller又是从webwork继承来的，而struts1.0也不是这么设计的。
首先：

从webwork开始到struts2为止，设计理念是用controller的成员变量来接收前台页面的参数及值，这样带来的好处显而易见，开发阶段很容易，但是带来的后果是成员变量会带来并发的问题，我不得不把controller设计成非单例的，用性能来换取开发的便利。

但是springMVC实际上使用的是struts1的模式，利用局部变量实现这件事，利用实现WebArgumentResolver接口, 或者用formbean中转的形式来实现这种结果，但是controller就可以在大部分时候声明为单例了。来加快程序运行的效率。

自己的一些看法，若有不对请指正。