在页面输入数据绑定上，struts用的是ActionForm的自动绑定，webwork2是modeldriven的getModel()绑定，Spring的是在controller中声明command对象。

这里strus是最重的，页面要用标签，要继承ActionForm，action要对应到form，要有pojo；而webwork2和Spring相对轻一点，webwork2的action要实现ModelDriven接口，Spring要在SimpleFormController的声明中配置一个 command对象（或者在代码中显式调用setCommandClass()），然后再有pojo，两者实现代价应该说差不多。

在实现输入验证上struts在form（M）上做文章要继承ValidateForm，webwork2/Spring都在action上做文章。

其中Spring比较特殊，它是编程式的验证；而struts/webwork2都是配置式的验证，在这一点上更倾向struts/webwork2。

即使出现struts/webwork2常规预定义验证不能处理的情况，也可以自己写一些验证规则，而且事实上也写过，当然很少要自己动手写规则:)。

又想起一点来，struts写规则写的是validate-rules.xml文件，而webwork2写的是java类，前者方便后者习惯，选择哪个框架就对哪个框架下手，没什么说的。

这里有一点应该提出来，要用输入验证，页面上必须用标签绑定输入项，这一点三者是一样的。

在国际化上，三者实现类似。

配置文件方面，Spring、struts、webwork2都差不多，难度相当。

Spring 一般还要多写一个application.xml来维护DP；struts要多写一个validate-forms.xml（好像是这个文件名，老了，忘了:(），所有要验证的页面都可以在这个文件里配置；webwork2则比较麻烦，要对所有要验证的页面，都写一个对应action的action- validation.xml文件。

其实偶一直认为MVC其中的model部分是比较难办的，如果model层完成全部的业务，就会仅为了MVC而忽略业务部分的分层合理化。

Spring、struts、webwork2三者的MVC都很好的实现了V和C两层，model层的实现相对来说就不那么清晰明确，业务是复杂的本身就应该分层实现。

上面把ValueObject一层划为model其实颇为牵强。

Spring是强大完备的，这从仅仅它的MVC部分就能和struts/webwork2相媲美就能看出来。

说明：“轻”或“重”指的是实现代价实现成本的大小。