航向新世界

你或許有聽過 MVC, 也或許您正在使用 MVC. 但您知道 MVC 的歷史嗎 ?

MVC 歷史

MVC 概念

將domain objects (model)與presentation objects (view and controller)清楚的分

離開來。MVC使用了Observer-Synchronization機制來支持單一個 domain object對

多個presentations還能保持著domain objects完全不認識 presentation objects 的

狀態。

View 視窗上的元件

可以是 button, label... 用於顯示 model data. 可以直接與 model 溝通.
請記得現在我們講的是80年代的視窗元件，這時候的元件只能顯示，他們本身並沒有事件偵測能力，所以不會知道User有沒有敲鍵盤，有沒有按滑鼠.

Controller 一個與 view 配對的邏輯實體

負責處理 User 的輸入, 如鍵盤、滑鼠等. 可以直接與 model 溝通

Model 一群 business objects

主要儲存資料，與DB互動. 提供服務處理業務邏輯. 完全與UI無關，而且也不知道任何的 view 或 controller.

Application Model MVC

繼 MVC 之後 Smalltalk 在 MVC 中增加了一個新的 Entity，Application Model (AM)。AM的加入是為了將model中有關presentation logic 的責任分離出來。AM

扮演著 model 與 presentation objects (view and controller) 之間的中介角色，而且 controller 與 view 不能夠直接存取 model，也不能向model 註冊 event，取而代之的只能存取 AM 與向 AM 註冊event。

MVP

第一代 MVP 於 1996 年由 Mike Potel 發表，且被 IBM 實作在當時的下一代C++與Java語言模型中。當時 Smalltalk 的下一代framework, “Dolphin Smalltalk”, 正在找尋新的 MVC 架構來補足Application Model MVC 的缺點。他們找到了 IBM 關於 MVP

應用的論文，且應用至Dolphin Smalltalk。Dolphin Smalltalk 的MVP 模式至今仍然適用。他依舊是rich-client 與 thin-client 應用程式的基本架構，如 .NET Framework.

2006, Martin Fowler 替Dolphin Smalltalk使用的MVP模型命名為『Supervising Controller』;另一種為 Application Model MVC的變形則命名為『Passive View』。

拜Microsoft所賜, 我們可以直接由 widget 捕捉滑鼠與鍵盤的事件，所以不再需要 controller 來做這件事情。另一個問題, 儘管 Application Model 是負責 View 的邏輯 (負責 push button, menu command, enabling And disabling view widgets or changing colors and such like)，但是卻只能透過 Observer Synchronization 與 view 溝通, 看起來一點也不合理. 所以 MVC 的 3 個 Role 該是需要重新定義其責任了..

View 為 widgets 的組合

負責將 user 的 action 轉給 presenter

目的是顯示model data

Presenter 負責顯示邏輯

下命令給 model

依據應用程式的規則變更顯示

與 view 之間有強烈偶合

Model 一組企業物件

負責解決問題領域

與資料庫互動

處理業務邏輯

完全不認識 view 與 presenter

MVC 與 MVP 的差別在哪?

MVC in ASP .NET

ASP .NET MVC Framework 自動由URL的對應設定找到controller。而 URL 必須符合 (/[controller name]/[action]/[action parameters])。ASP .NET 會依照預先設定的Controller Mapping Route Table 找到 controller，該 controller 中則實作 action 方法，ASP .NET MVC Framework 會自動調用到 controller 中的 action。

在 action 中可以進行資料的處理，並透過 RenderView 方法回覆View 到 Client 端。

思考

1. 為什麼要用這樣的 URL ? 有什麼優點?

2. 如果您的 Web 要改成這樣的用法該怎麼改? URL會變成怎樣 ?

3. Application Controller (負責 Page Flow) 在什麼情況下適合使用 ?

4. Application Controller 還有怎樣的優點 ?

延伸

我們可以使用 MVPC 模式來建立 UI 應用嗎 ?

該怎麼使用呢 ?