作者：
江南白衣 Struts与Webwork的扇子请跳过本篇。
MVC不就是把M、V、C分开么？至唯物朴素的做法是两个JSP一个负责View，一个负责Controller，再加一个负责Model的Java Bean，已经可以工作得很好，那时候一切都很简单。
而现在为了一些不是本质的功能，冒出这么多非标准的Web框架，实在让人一阵郁闷。像Ruby On Rails那样简捷开发，可用可不用，而且没有太多的限制需要学习的，比如
Webwork这型还可以考虑。但像Struts那样越用框架越麻烦，或者像Tapestry那样有严重自闭倾向，额上凿着"高手专用玩具"的，用在团队里就是不负责任的行为了。
so，我的MVC方案是使用Spring MVC的Controller接口，写最普通的JavaBean作为Controller，本质就和当年拿JSP作Controller差不多，但拥有了Spring IOC的特性。
之所以用这么消极的选择标准，是因为觉得这一代MVC框架离重回RAD时代的标准还很远，注定了只是一段短暂的，过渡的技术，不值得投资太多精力和团队学习成本。
1. 原理
Spring MVC按植物分类学属于Martin Flower〈企业应用模式〉里的静态配置型Front Controler，使用DispatchServlet截获所有*.do的请求，按照xml文件的配置，调用对应的Command对象的handleRequest(request,response)函数，同时进行依赖对象的注入。
我们的Controller层，就是实现handleRequest(request,response)函数的普通JavaBean。
2. 优势
Spring MVC与struts相比的优势:
一是它的Controller有着从松到紧的类层次结构，用户可以选择实现只有一个HandleRequest()函数的接口，也可以使用它有很多回调函数的SimpleFormController类。
二是不需要Form Bean，也不需要Tapestry那所谓面向对象的页面对象，对于深怕类膨胀，改一个东西要动N个地方的人最适合不过。
三是不需要强XML配置文件，宣告式编程是好的，但如果强制成框架，什么都要在xml里面宣告，写的时候繁琐，看的时候也要代码配置两边看才能明白就比较麻烦了。
那Webwork呢?没有实战过，不过因为对MVC框架所求就不多，单用Spring MVC的Controller已经可以满足需求，就不多搞一套Webwork来给团队设坎，还有给日后维护，spring,ww2之间的版本升级添麻烦了。真有什么需要添加的，Spring MVC源代码量很少，很容易掌控和扩展。
3.化简
3.1. 直接implement Controller，实现handleRequest()函数
首先，simple form controller非我所好，一点都不simple。所以有时我会直接implement Controller接口。这个接口的唯一函数是供Front Controller调用的handleRequest(request,response)。
如果需要application对象，比如想用application.getRealPath()时，就要extends webApplicationObjectSupport。
3.2.每个Controler负责一组相关的action
我是坚决支持一个Controler负责多个action的，一个Controler一个action就像一个function一个类一样无聊。所以我用最传统的方式，用URL参数如msg="insert"把一组相关action交给一个Controler控制。ROR与制作中的Groovy On Rails都是这种模式，Spring也有MultiActionController支持。
以上三者都是把URL参数直接反射为Controller的函数，而
Stripes的设计可用annotation标注url action到响应函数的映射。
我的取舍很简单，反正Spring没有任何强制，我只在可能需要不重新编译而改变某些东西的时候，才把东西放在xml里动态注入。jsp路径之类的就统统收回到controller里面定义.
3.4.Data Binder
Data Binder是Controller的必有环节，对于Spring提供的DataBinder，照理完全可用，唯一不爽是对象如果有内嵌对象，如订单对象里面包含了Customer对象，Spring需要你先自行创建了Customer对象并把它赋给了Order对象，才可能实现order.customer.customer_no这样的绑定。我偷懒，又拿Jakarta BeanUtils出来自己做了一个Binder。
3.5.提取基类