經典MVC
在1979年，經典MVC模式被提出。
在當時，人們一直試圖將純粹描述思維中的物件與跟計算機環境打交道的程式碼隔離開來，而Trygve Reenskaug在跟一些人的討論中，逐漸剝離出一系列的概念，最初是Thing、Model、View、Editor。後來經過討論定為Model、View和Controller。作者自言“最難搞的就是給這些架構元件起名字”。
因為當時的軟體環境跟現在有很大不同，所以經典MVC中的概念很難被現在的工程師理解。比如經典MVC中說：“view永遠不應該知道使用者輸入，比如滑鼠操作和按鍵。”對一個現代的軟體工程師來說，這聽上去相當不可思議：難道監聽事件不需要類似這樣的程式碼嗎？
view.onclick = ......
但是想想在70年代末，80年代初，我們並沒有作業系統和訊息迴圈，甚至滑鼠的游標都需要我們的UI系統來自行繪製，所以我們面對的應該是類似下面的局面：
mouse.onclick = ......mouse.onmove = ......
當滑鼠點選事件發生後，我們需要通過view的資訊將點選事件派發到正確的view來處理。假如我們面對的是滑鼠、鍵盤驅動這樣的底層環境，我們就需要一定的機制和系統來統一處理使用者輸入並且分配給正確的view或者model來處理。這樣也就不難理解為什麼經典MVC中稱"controller是使用者和系統之間的連結"。
因為現在的多數環境和UI系統設計思路已經跟1979年完全不同，所以現代一些喜好生搬硬套的"MVC"實現者常常會認為controller的輸入來自view，以至於畫出model、view、controller之間很奇葩的依賴關係：
[img=UI,架構]https://camo.githubusercontent.com/7dfc219a18bf7ee6de1c4c31c1c6e17f9c635fe8/687474703a2f2f6465766262732d64697363757a782e73746f722e73696e616170702e636f6d2f75635f7365727665722f666f72756d2f3230313530322f30332f313931353238776b37757775307375726d756b6b32762e706e67[/img]
我們來看看Trygve Reenskaug自己畫的圖（這惡趣味的骷髏啊……）：
[img=UI,架構]https://camo.githubusercontent.com/17749aa6915f9bab027dddc91783c86ac0a2010c/68747470733a2f2f6865696d2e6966692e75696f2e6e6f2f253745747279677665722f7468656d65732f6d76632f4d56432d323030362e676966[/img]
值得一提的是，其實MVC的論文中，還提到了"editor"這個概念。因為沒有出現在標題中，所以editor聲名不著。MVC論文中推薦controller想要根據輸入修改view時，從view中獲取一個叫做editor的臨時物件，它也是一種特殊的controller，它會完成對view和view相關的model的修改操作。
控制元件系統
MVC是一種非常有價值的架構思路，然而時代在變遷，隨著以windows係為代表的WIMP（window、icon、menu、pointer）風格的應用逐漸成為主流，人們發現，view和controller某些部件之間的區域性性實際上強於controller內部的區域性性。於是一種叫做控制元件（control）的預製元件開始出現了。
控制元件本身帶有一定的互動功能，從MVC的視角來看，它既包含view，又包含controller，並且它通過"屬性"，來把使用者輸入暴露給model。
controller的輸入分配功能，則被作業系統提供的各種機制取代：
MVP
1996年，Taligent公司的CTO，Mike Potel在一篇論文中提出Model-View-Presenter的概念。
在這個時期，主流的view的概念跟經典MVC中的那個“永遠不應該知道使用者輸入”的view有了很大的差別，它通常指本文中所述的控制元件，此時在Mike眼中，輸入已經是由view獲得的了：
[img=UI,架構]https://camo.githubusercontent.com/c3dd0f9f77b116f5b5b4ce9fb82ac136a68664b3/687474703a2f2f7777322e73696e61696d672e636e2f6d773639302f34373465626633356777316570346f6b727a34716a6a32306f6d3065753430352e6a7067[/img]
完整內容點此檢視
在1979年，經典MVC模式被提出。
在當時，人們一直試圖將純粹描述思維中的物件與跟計算機環境打交道的程式碼隔離開來，而Trygve Reenskaug在跟一些人的討論中，逐漸剝離出一系列的概念，最初是Thing、Model、View、Editor。後來經過討論定為Model、View和Controller。作者自言“最難搞的就是給這些架構元件起名字”。
因為當時的軟體環境跟現在有很大不同，所以經典MVC中的概念很難被現在的工程師理解。比如經典MVC中說：“view永遠不應該知道使用者輸入，比如滑鼠操作和按鍵。”對一個現代的軟體工程師來說，這聽上去相當不可思議：難道監聽事件不需要類似這樣的程式碼嗎？
view.onclick = ......
但是想想在70年代末，80年代初，我們並沒有作業系統和訊息迴圈，甚至滑鼠的游標都需要我們的UI系統來自行繪製，所以我們面對的應該是類似下面的局面：
mouse.onclick = ......mouse.onmove = ......
當滑鼠點選事件發生後，我們需要通過view的資訊將點選事件派發到正確的view來處理。假如我們面對的是滑鼠、鍵盤驅動這樣的底層環境，我們就需要一定的機制和系統來統一處理使用者輸入並且分配給正確的view或者model來處理。這樣也就不難理解為什麼經典MVC中稱"controller是使用者和系統之間的連結"。
因為現在的多數環境和UI系統設計思路已經跟1979年完全不同，所以現代一些喜好生搬硬套的"MVC"實現者常常會認為controller的輸入來自view，以至於畫出model、view、controller之間很奇葩的依賴關係：
[img=UI,架構]https://camo.githubusercontent.com/7dfc219a18bf7ee6de1c4c31c1c6e17f9c635fe8/687474703a2f2f6465766262732d64697363757a782e73746f722e73696e616170702e636f6d2f75635f7365727665722f666f72756d2f3230313530322f30332f313931353238776b37757775307375726d756b6b32762e706e67[/img]
我們來看看Trygve Reenskaug自己畫的圖（這惡趣味的骷髏啊……）：
[img=UI,架構]https://camo.githubusercontent.com/17749aa6915f9bab027dddc91783c86ac0a2010c/68747470733a2f2f6865696d2e6966692e75696f2e6e6f2f253745747279677665722f7468656d65732f6d76632f4d56432d323030362e676966[/img]
值得一提的是，其實MVC的論文中，還提到了"editor"這個概念。因為沒有出現在標題中，所以editor聲名不著。MVC論文中推薦controller想要根據輸入修改view時，從view中獲取一個叫做editor的臨時物件，它也是一種特殊的controller，它會完成對view和view相關的model的修改操作。
控制元件系統
MVC是一種非常有價值的架構思路，然而時代在變遷，隨著以windows係為代表的WIMP（window、icon、menu、pointer）風格的應用逐漸成為主流，人們發現，view和controller某些部件之間的區域性性實際上強於controller內部的區域性性。於是一種叫做控制元件（control）的預製元件開始出現了。
控制元件本身帶有一定的互動功能，從MVC的視角來看，它既包含view，又包含controller，並且它通過"屬性"，來把使用者輸入暴露給model。
controller的輸入分配功能，則被作業系統提供的各種機制取代：
- 指標系統：少數DOS時代過來的程式設計師應該記得，20年前的程式中的“滑鼠箭頭”實際上是由各個應用自己繪製的，以MVC的視角來看，這應當屬於一個"PointerView"的職責範疇。但是20世紀以後，這樣的工作基本由作業系統的底層UI系統來實現了。
- 文字系統：今天我們幾乎不需要再去關心文字編輯、選中、拖拽等邏輯，對web程式設計師可以嘗試自己用canvas寫一個文字編輯框來體驗一下上個時代程式設計師編寫程式的感受。你會發現，選中、插入/覆蓋模式切換、換行、退格、雙擊、拖拽等邏輯異常複雜，經典MVC模式中通常使用TextView和TextEditor配合來完成這樣的工作，但是今天幾乎找不到需要我們自己處理這些邏輯的場景。
- 焦點系統：焦點系統通過響應滑鼠、tab鍵等訊息來使得控制元件獲得作業系統級唯一的焦點狀態，所有的鍵盤事件通常僅僅會由擁有焦點的控制元件來響應。在沒有焦點系統的時代，作業系統通常是單任務的，但是即使是單一應用，仍然要自己管理多個controller之間的優先權和覆蓋邏輯，焦點系統不但從技術上，也從互動設計的角度規範化了UI的輸入響應，而最妙的是，焦點系統是對視覺障礙人士友好的，現在頗多盲人用讀屏軟體都是強依賴焦點系統的。
MVP
1996年，Taligent公司的CTO，Mike Potel在一篇論文中提出Model-View-Presenter的概念。
在這個時期，主流的view的概念跟經典MVC中的那個“永遠不應該知道使用者輸入”的view有了很大的差別，它通常指本文中所述的控制元件，此時在Mike眼中，輸入已經是由view獲得的了：
[img=UI,架構]https://camo.githubusercontent.com/c3dd0f9f77b116f5b5b4ce9fb82ac136a68664b3/687474703a2f2f7777322e73696e61696d672e636e2f6d773639302f34373465626633356777316570346f6b727a34716a6a32306f6d3065753430352e6a7067[/img]
完整內容點此檢視