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