Model View Controller Design Pattern

在 1970 年代末期，當 GUI 發明出來時，軟體設計師看見應用程式有三 個主要部份：處理資料的部份、建立畫面和報表的部份、以及處理用戶和其

他子系統之間互動的部份。在 1980 年到初期，ObjectWorks/Smalltalk 程式 設計環境引入了這三位一體的觀念作為開發架構。以 Smalltalk 80 的說法，

資料系統稱為模型(Model)，版面配置系統稱為外觀(View)，而互動系統就 稱為控制元(Controller)[11]。

Smalltalk MVC 架構在一本相當著名的書 ” Design Pattern: Elements of Resuable Object-oriented Software”，其中有通知/訂閱協定(notify/subscribe protocol)以及觀察者設計模式(Observer pattern)的範例，此範例的本質是系統 需要替相同資料顯示不同的外觀，像是條狀圖、扇形圖、以及試算表。這是 劃分應用程式的絕佳基由，而且這個範例也常在許多地方被引用。

圖 19 模型資料可以用在不同的外觀內

如上圖，每一種外觀可以在同一時間顯示給不同的用戶看。應用程式必 須在底層資料或是模型(Model)變更時，隨時保持外觀能隨之更新。為了更 新模型，用戶交付一道請求給控制元，再由控制元來協調模型的變更。然後，

顯示資料的外觀必須跟著更新，來反應模型的最新狀態。

Smalltalk MVC 手段是使用一個觀察者通知設計模式(Observer

notification pattern)。在這個設計模式中，每種外觀都註冊成模型資料的觀察

者。接著模型可以送出一道訊息通知所有已註冊的觀察者以通知外觀做更 新。後來 Smallalk MVC 架構被修正成通用的 MVC 架構標準，使其能適用 任何平台的程式建造工程。

圖 20 MVC 架構

上圖為 MVC 最常採用的標準模式圖：一個三角形，三角上有互相連接 的元件。網站應用程式要維護圖中「變更通知」的部份是相當困難的。當所 有的資源都位在相同伺服器上，而且客戶端和伺服器之間的連線維持不斷 時，這種情形當然可以處理得很好。但是當資源是分散在好幾台伺服器上，

而且客戶端和伺服器上的應用程式之間並沒有維持不斷的連線時，處理的困 難度便提高很多。

很多分散系統的建構者，包括網站應用程式在內，都會避開讓外觀做狀 態查詢的想法。最常見的是，遠端應用程式會以分層設計模式(Layers pattern) 來設計，也就是說必免同層或相鄰層的類別此互動，對複雜的應用程式而 言，這樣可以避免新增元件時，複雜度呈指數成長。分層在設計遠端應用程 式上是核心的設計模式。

版面配置層 控制元層 應用程式 系統之實際讀寫，皆在此進行，Model 從從 Controller 取得資料，並實際對 Model 的 Instance 進行設值動作，並提供 Interface 供 View 及 Controller 使用。

2. View

負責畫面之呈現，由 Controller 控制選擇 View，使用者輸入的事件也從 View 觸發並通知 Controller，另外，此層不應有商業邏輯存在。

3. Controller

Controller 更改 Model 之資料，接受所有 Client 透過 View 傳來之 request，當 Model 有所改變時通知 View 作畫面的調整。