基於請求響應的MVC架構調用分析

標籤：jps   one   spin   lib   off   pod   ddms   推斷   air   

一。使用Servlet來處理請求響應

                 當client提交資料之後。接著發送請求，請求被封裝成對象，server接收到請求，依據請求的URL。來推斷將請求對象交由哪個Servlet處理。

在servlet中，我們能夠依據請求是從哪裡發出的。來推斷我們詳細運行哪段處理表現層商務邏輯的if-else.或者。可能我們client會提交一個參數，我們能夠依據參數來推斷調用哪段代碼去渲染表現層。返回給client。不管是怎麼推斷，中間的選擇都是要得出我們要返回哪個表現層，比如。返回哪個JSP。

               當表現層越來越多的時候。我們的選擇邏輯越來越龐大，並且，每次添加一個表現層，我們就要在servlet裡面，if -else進去返回這個表現層的介面邏輯代碼。首先。if-else過長是一個問題，並且。每次改動代碼，嚴重違反了我們的開放封閉原則。

            事實上，使用了servlet之後，已經有明顯的MVC的思想了。形式上也有MVC的意思，僅僅是一些小的不足，改進這些不足，就會誕生更成熟的MVC實踐。

         首先是改進IF-Else的問題，針對我們曾經的設計經驗。if-else過長。我們選擇的是工廠+反射來改進。

這樣。在這裡，我們就拆出來非常多處理請求響應的類。另外。反射是依賴設定檔的，所以。也會多出來一個設定檔，來配置我們在動態調用的時候。詳細執行個體化哪一個類來處理請求響應。if-else處理掉了，所以後面的開放封閉的問題也就不存在了。

       基於上面這個思路實現的MVC架構，想象中還是蠻美好的。

二。sturts的請求響應分析

以下來分析下struts中，是怎樣處理請求響應的：

       前面過程事實上一樣。首先client發送請求。請求地址是符合我們servlet配置的url-name的。所以當server接收到請求的時候，建立完請求響應對象，會依據我們配置的url-name截取出URL，然後通過各種推斷，之後。找到處理這個請求響應的類，當這個類處理完畢之後，會返回一個專向的資訊，資訊裡面至少包括：轉向地址（轉到哪裡去）。和請求響應資訊等。

      之後，我們的前端負責介面展現的servlet（在架構中已經被做好了）會幫我們將響應分發給對應的視圖。

      添加了struts之後，相比直接使用Servelt，我們屏蔽掉非常多細節上的實現跟代碼上的壞味道。讓開發過程中更關注相對變化的東西。

            

基於請求響應的MVC架構調用分析