最近不是很忙，於是決定了解一下關於J2EE的相關內容。現在已基本知道Servlet和JSP是怎麼回事， 目前正在看Struts.在看Struts的過程中，我一直存在一個疑惑：為什麼要使用Struts呢？
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的最大好處。規范程序員的行為，讓程序在不知不覺中寫出符合優秀架構的代碼，這應該是所有框 架的共同目的，也應該是根本目的。
