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的最大好處。規范程序員的行為，讓程序在不知不覺中寫出符合優秀架構的代碼，這應該是所有框架的共同目的，也應該是根本目的。