Struts是對MVC2模型的實現,於是許多講解Struts的書用Servlet做了個符合MVC2要求的Web應用,再用Struts做了個同樣功能的Web應用.但是在對兩種方式的對比中,我發現Struts似乎並沒有為開發者帶來很大的方便.以下是我的對比：
視圖：兩者一樣
控制器：利用Struts並不能完全擺脫這一層,開發者還是需要寫Action.使用Servlet方式,也是寫一個同Action一樣的Servlet充當控制器.兩者在代碼量上沒有區別,在程序邏輯上也一樣；
模型：兩者一樣
兩者的主要差別：Struts多了一個ActionServlet
既然編寫一個類似Acition的Servlet就可以充當控制器,那麼Struts在提供Action后,ActionServlet的意義何在？
ActionServlet的作用是攔截用戶請求,並將用戶請求轉發給合適的Action,而自己的Web應用是將用戶請求直接發送給功能等同於Action的自定義Servlet.ActionServlet在攔截過程中注入了一個ActionForm對象和一個ActionMapping對象.經過這個過程后,Struts為開發者帶來了如下實際的好處：通過ActionMapping,Action在轉發時,並不是轉發給一個實際的頁面.而是轉發給在strus-config.xml中已經配置的對象.這意味著,在不改變Action代碼的情況下就可以更換其轉發的頁面；如果沒有ActionMapping,當有100個Action都要更換轉發頁面時,我們不得不在龐大的Web應用中找出這100個Action,修改其轉發頁面,然後再重新編譯它們.有了ActionMapping后,只需要在struts-config.xml中修改相應的配置即可,這樣既查找方便,又不用重新編譯.
現在的一個主要問題是：Web應用一旦投入使用之後,更換轉發頁面的可能性有多大？Action轉發的頁面,一般都是直接向用戶展示的JSP頁面.軟體工程中,一切和用戶直接打交道的部分都是極易發生變化的.
當然Struts肯定還有其它方面的便利之處,但是這些還並不足以打動我去使用Struts,即便它還提供了豐富的標籤庫.
最終一個重要的原因讓我認為我的確需要採用像Struts這樣的框架.當然,首先我一直是相信MVC模型所倡導的理念的：將視圖和模型分開.把和用戶交互的部分獨立出來的好處是明顯的.
首先如前面所述,和用戶交互的部分是最易發生變化的,視圖的獨立意味著變化的隔離；然後是將視圖分離出去后,開發者可以將精力集中在對業務流程的處理上.一個大型的系統,最複雜的最核心的部分就是處理業務流程.可是實際的情況是,繁瑣地界面處理佔用了程序員大量甚至是大部分的時間.
我相信了MVC模型帶來的好處,
開發Web應用時我一定會採用這種模式,但是我並不需要Struts,
Servlet就可以讓我實現MVC模型.我的這種想法似乎很自然,但是這裡面隱含著一個前提是：我每次開發Web應用,都必須有意識的嚴格按照MVC規範來寫.這看起來不是很困難,但是做起來卻很難.
有時候在業務處理過程中嵌入幾行關於界面的代碼似乎是非常自然
簡單的,於是我就真的這樣做了.一段時間之後,我突然發現我的業務處理過程和界面顯示部分又混雜在一起了.至此我才真正相信我要使用Struts.
Struts可以規範程序員的行為.也許Struts並不能降低實際的代碼量,甚至有時候不使用Struts的代碼可能更簡潔,但是按照Struts寫出來的Web應用卻一定是符合MVC模型的.就我認為,這是採用Struts的最大好處.規範程序員的行為,讓程序在不知不覺中寫出符合優秀架構的代碼,這應該是所有框架的共同目的,也應該是根本目的.
