strust架構思想複習

很久沒有接觸這些個web架構，從頭兒過一遍

首先，struts 的目的 簡單來說，是以servlet為基礎的。

如果要說servlet 就不得不說一下 web容器。

什麼是web容器，在我的概念中，web容器就是一個複雜的socket 。監聽某連接埠等待別的socket來請求，並返回請求結果字串/流 給客戶機。

那麼，web 有兩個環節就是最重要了

一，socket是接受請求，並用啟用多線程來進行處理。

二，根據不同的請求，返回相應的內容。用socket寫回去。

而後來，我們發現，這個監聽並接受socket請求的模組，以及因為協議的問題，我們能得到一個規範的request 和 產生一個規範的response

這些內容可以說都是簡單並且是重複的。所以，我們將其抽出來，就成了web容器。所以，一旦我們擁有了web容器，我們就得到了一個可啟動監聽的，並且能將socket封裝成request以及response的這麼一個工具。然後，我們就可以通過這個根據request的url來找到對應的我們自訂的servlet 來進行處理，並產生相應的文本，然後寫回去，從而完成整個web流程。

那麼，我們逐漸對我們自訂的servlet不滿意了。為什嗎？ 因為，每次在java代碼中拼字串，很狼狽，也不夠優雅。同時，根據功能，一部分servlet代碼是用來查詢資料庫，處理邏輯判斷。而一部分servlet代碼，就是拼接結果字串。於是，我們就將拼接字串的這部分代碼給拆分出去。用另外一種形式來拼接字串，比如jsp，比如struts ，比如velocity 目的就是用處理邏輯的servlet得到結果對象，然後將這寫結果對象傳入jsp頁面，或者template裡，並按照一定的邏輯或者文法順序來形成了頁面，這個頁面，也就是我們拼接好的字串。最後將這個字串寫回用戶端，自此，一個動態頁面就產生了。

當然，針對處理邏輯的servlet我們也進行了拆分。在這裡我們先不贅述，等到複習hibernate的時候，自然就會需要拆分這部分代碼。

而在這裡，我們的struts就應需求而生了，應什麼需求，個人認為，需要將邏輯和頁面分開，行成MVC模式。。。又見MVC。多少書上對這個MVC進行了強調，再強調。其實，簡單來說，就是將代碼分離，邏輯業務的就是邏輯和業務，而跟頁面有關的諸如產生頁面，或者從請求中擷取資料，都是頁面的事兒。

而且，struts有一個突破。就是單servlet 多action的方式。將很多的servlet集中在了一起。並且通過設定檔來寫這些東西，這樣，首先，降低了耦合率，成功和失敗的跳轉頁面都寫在了設定檔中。這樣，如果修改一個jsp的檔案名稱，那麼，我們僅僅在一個設定檔中修改了就可以，而不用到各個的servet中去尋找並修改。集中管理，這是好處之一。第二個不錯的地方就是，如果我們要用jsp並，按照邏輯代碼和頁面代碼分離的思想，那麼，如果一個沒有參數的不需要請求資料庫的頁面，我們也得為其寫兩個servlet ，而顯然，類似這種的adduser.jsp login.jsp 很多，那麼，我們可以寫一個公用的Action 讓他們統統success 來各自在設定檔中找到自己相應的jsp就可以了。 

當然了，struts 是一個工具，一個MVC的工具。裡麵包含了很多能方便使用的東西，比如ActionForm 比如DynaActionForm等等內容。以及Valider ，便於開發，簡便開發。是struts的目的，我們學習工具，不是為了說盲目的，因為公司使用，而去使用它，而是要根據他解決了什麼問題，對我們有什麼好處而去使用它，這樣，我們才能知道什麼是優勢，什麼是劣勢。才能讓我們更好的使用工具為我們的專案服務。而不是為工具所累。

原文地址：http://blog.csdn.net/kfanning/archive/2011/06/24/6566313.aspx 轉載請保留，謝謝