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到響應函數的映射。
3.3.xml宣告式編程的取捨
我的取捨很簡單，反正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.提取基類
最後還是忍不住提取了一個基類，負責MultiAction和其他一些簡便的方法。Sprnig的MultiActionController做得太死，規定所有函數的第1,2個參數必須是request和response，不懂動態的，溫柔的進行參數注入。
經過化簡再化簡，已經是很簡單一個Java Bean ，任誰都可以輕松上手，即使某年某月技術的大潮把現在所有MVC框架都淹沒了，也不至於沒人識得維護。
