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