軟體架構模式中,MVC是開發者耳熟能詳的,然而由於Web應用程式的流行,今日多數開發者談及MVC聯想到的,其實是Model 2。

基本上,MVC與Model 2都是將系統畫分為Model、View和Controller三個部份,最大不同在於Model與View間的互動方式,隨著軟、硬體技術的進化與應用程式規模的擴展,MVC/Model 2的應用方式也在調整、改變與結合。

傳統桌面MVC模式
在MVC中最易理解的部份,是使用者可見與操作的View,具體實例之一是視窗畫面,而MVC基本工作流程之一從使用者在畫面上操作開始,此操作對Controller發出請求,Controller根據請求的類型與參數,將請求轉發(或呼叫)對應Model進行處理,之後Controller可轉發請求至View,View會提取Model資料呈現結果;另一個可行工作流程是Model處理後狀態有變,通知對Model狀態有興趣並曾註冊的View,由View提取Model資料以呈現最新結果。

MVC模式的好處:
一、藉由Controller協調,View不會直接對Model作出任何變更,View只負責呈現邏輯(Presentation logic),即根據Model資料呈現結果,相關操作對應的商務邏輯(Business logic)不在View中。

二、Controller負責商務邏輯中請求參數的收集與驗證,更複雜的商務邏輯轉交Model處理,這使得Controller維持輕巧,Model也具有較高的重用性,Controller也負責調配對應的View,所以Model不會與View耦合。

三、Model不會知道或決定View實際呈現方式,因此View可以獨立於Model,自由變化。

四、Model狀態有變化時,曾向Model註冊過的多個View,都可獲得通知而得到同步更新效果。

第三項也許是最重要的優點,相較於Controller與Model來說,View相對來說最常變化,畢竟使用者往往對操作畫面要求最多也最善變,將Model與View切割後,Model就可以相對穩定地進行發展;而且View往往會由專門的使用者介面設計者負責,可能是專門的美術或設計師,未必擅長實際採用的技術,但可透過工具進行介面設計,讓View可以獨立於技術成份重的Model,自由變化,有助於團隊成員間的分工合作。

基於HTTP的Model 2模式

實際上MVC模式本身並沒有明確定義,因而採納MVC模式中最大特徵「將系統畫分為Model、View和Controller三個部份」,並將三個部份的互動流程因實際應用場合進行調整,都可說是一種MVC模式,其中最為人熟悉的,就是Web應用程式經常採用的Model 2,又稱Web MVC,或由於過於流行而直接稱MVC了。

Web應用程式先天上,會被畫分為Model、View和Controller三個部份,View通常是客戶端的瀏覽器依取得的HTML繪製畫面,Controller位於Web伺服器,與資料庫互動的則是Model;傳統MVC模式實作的桌面應用程式,MVC三個部份通常位於同臺電腦,或者是透過持續網路連線互動。

然而,對於基於HTTP的Web應用程式來說,由於HTTP基於請求/回應(Request/Response)模型,沒有請求就不會有回應,因此無法實現傳統MVC中Model主動通知View的流程,如果View想根據Model最新狀態來呈現畫面,基本作法之一,是透過持續性地主動詢問(Poll)伺服端Model來達成。

基於HTTP限制而調整傳統MVC互動流程,得到的模式稱為Model 2,除了Model無法主動View外,基本上它的優點與傳統MVC前三項優點是相同的。

Model 2概念最早出現在1998年JSP規格書0.92版中,規格書中提及兩個模型,第一個模型稱為Model 1(因為文件提及的順序),第二個模型稱為Model 2。1999年Govind Seshadri在Javaworld發表了《Understanding JavaServer Pages Model 2 architecture》文章,其影響之一是將Model 2界定為架構模式,第二個影響是確立Model 2為Web應用程式提供了一種MVC架構。

Model 1中通常會將請求發給某個網頁動態元件(例如JSP或Servlet),由它處理請求參數收集、驗證、商務處理以及畫面回應,有些商務邏輯亦可能會封裝成Model(例如JavaBean),然而前端元件亦要處理請求參數收集、驗證與畫面回應,程式碼與畫面設計勢必形成義大利麵式的混亂,也因而Model 1通常應用在規模較小、任務簡單的Web應用程式。

MVC與Model 2的異同
儘管由於HTTP模型限制,使得Model 2無法達成傳統MVC中Model主動通知View的流程,然而MVC與Model 2有許多相似點,除了系統同被畫分為Model、View和Controller三個部份之外,Model 2中通常根據URL模式(Pattern)決定哪個Controller要接收View發送的請求參數,實際上在傳統MVC中,Controller名稱與方法簽署(Method signature)就相當於Model 2的URL模式,而方法的參數名稱與實際接收的引數,就相當HTTP請求中的參數名稱與值。

舉例來說,在實現Model 2時可定義從/messages/view?bid=34&id=123,決定使用MessagesController的view方法來處理bid與id請求參數;相對地,若有個桌面應用程式,畫面操作時若呼叫messagesController.view(bid, id),則messagesController變數結合view方法簽署,就相當於Model 2中URL模式,而bid與id變數就相當於請求參數。Web應用程式的網頁會設定發送表單的動作(action)對象,桌面應用程式會設定按鈕操作時呼叫的Controller與方法,兩者的意義實際是相同的。

隨著Ajax技術廣泛應用,以及伺服端非同步處理技術的進步,由於HTTP模型而造成的限制亦逐漸被克服。Web應用程式中為了取得Model最新狀態,即使使用傳統的持續詢問方式,已不再需要重清(Refresh)整個頁面,可利用Ajax在背景取得代表Model狀態的中性資料,而後用JavaScript更新畫面上相應的部分即可。

如果要作到更接近主動通知的概念,也就是在Model狀態有變化時,View可立即得到更新,伺服端可保留一定數量非同步請求,暫不回應,一旦Model狀態變化再進行回應,效果上就可達到傳統MVC模型中Model主動通知View的流程。

職責轉變多樣化的MVC/Model 2

隨著JavaScript、DOM、Ajax應用日漸廣泛,甚至HTML5新API的推波助瀾,同一Web應用程式中實現傳統MVC與Model 2的場合,越來越常見。

傳統Web應用程式中View原本由伺服端產生相關畫面,現在轉移給瀏覽器更動態的呈現,瀏覽器亦可有自成一體的應用程式,由HTML、DOM、CSS作為View的實現,JavaScript用以實現Controller與Model,就能在瀏覽器中實現傳統MVC模式應有流程,瀏覽器中JavaScript撰寫的Model,可將伺服端比擬為資料庫,向伺服端取得資料,就像對資料庫查詢,Ajax是與伺服端溝通的機制,伺服端傳回的資料,可能是中性格式、HTML或CSS組成的畫面片段,甚至是一段待執行的JavaScript程式碼。

無論如何,傳統Model 2中View的職責減輕了,這有助於開發者職責的畫分。過去由伺服端產生所有回應畫面的情境下,網頁設計師雖可獨立於Model設計畫面,但使用的元件仍會與伺服端技術有關(像是JSTL自訂標籤等),如果採用的伺服端技術不同,設計師就得學習使用不同的元件。

當原本伺服端的View將組織畫面的職責卸下,交給瀏覽器處理之後,設計師可專心使用瀏覽器上的JavaScript、DOM、CSS等相關技術,只要協調好與伺服端的資料交換格式,設計師甚至可以先行製作假資料,完全獨立於伺服端工作進度之外,完成自身任務。

 

作者簡介


Advertisement

更多 iThome相關內容