1 前言
用戶界面，特別是圖形用戶界面，承擔著向用戶顯示問題模型和與用戶進行操作和I/O交互的作用。用戶希望保持交互操作界面的相對穩定，但更希望根據需要改變和調整顯示的內容和形式。例如，要求支持不同的界面標準或得到不同的顯示效果，適應不同的操作需求。這就要求界面結構能夠在不改變軟體的功能和模型情況下，支持用戶對界面構成的調整。
要做到這一點，從界面構成的角度看，困難在於：在滿足對界面要求的同時，如何使軟體的計算模型獨立於界面的構成。模型-視圖-控制（MVC：Model-View-Controller）就是這樣的一種交互界面的結構組織模型。
2 MVC（Model-View-Control）
MVC由Trygve Reenskaug提出，首先被應用在SmallTalk-80環境中，使許多交互和界面系統的構成基礎，Microsoft的MFC基礎類也遵循了MVC的思想。
對於界面設計可變性的需求，MVC把交互系統的組成分解成模型、視圖、控制三種部件。
模型部件是軟體所處理問題邏輯在獨立於外在顯示內容和形式情況下的內在抽象，封裝了問題的核心數據、邏輯和功能的計算關係，他獨立於具體的界面表達和I/O操作。
視圖部件把表示模型數據及邏輯關係和狀態的信息及特定形式展示給用戶。它從模型獲得顯示信息，對於相同的信息可以有多個不同的顯示形式或視圖。
控制部件是處理用戶與軟體的交互操作的，其職責是控制提供模型中任何變化的傳播，確保用戶界面於模型間的對應聯繫；它接受用戶的輸入，將輸入反饋給模型，進而實現對模型的計算控制，是使模型和視圖協調工作的部件。通常一個視圖具有一個控制器。
模型、視圖與控制器的分離，使得一個模型可以具有多個顯示視圖。如果用戶通過某個視圖的控制器改變了模型的數據，所有其它依賴於這些數據的視圖都應反映到這些變化。因此，無論何時發生了何種數據變化，控制器都會將變化通知所有的視圖，導致顯示的更新。這實際上是一種模型的變化-傳播機制。
2.1 MVC中的模型、視圖和控制類
（1） 模型包含了應用問題的核心數據、邏輯關係和計算功能，它封裝了所需的數據，提供了完成問題處理的操作過程。控制器依據I/O的需要調用這些操作過程。模型還為視圖獲取顯示數據而提供了訪問其數據的操作。
這種變化-傳播機制體現在各個相互依賴部件之間的註冊關係上。模型數據和狀態的變化會激發這種變化-傳播機制，它是模型、視圖和控制器之間聯繫的紐帶。
（2） 視圖通過顯示的形式，把信息轉達給用戶。不同視圖通過不同的顯示，來表達模型的數據和狀態信息。每個視圖有一個更新操作，它可被變化-傳播機制所激活。當調用更新操作時，視圖獲得來自模型的數據值，並用它們來更新顯示。
在初始化時，通過與變化-傳播機制的註冊關係建立起所有視圖與模型間的關聯。視圖與控制器之間保持著一對一的關係，每個視圖創建一個相應的控制器。視圖提供給控制器處理顯示的操作。因此，控制器可以獲得主動激發界面更新的能力。
（3） 控制器通過時間觸發的方式，接受用戶的輸入。控制器如何獲得事件依賴於界面的運行平臺。控制器通過事件處理過程對輸入事件進行處理，並為每個輸入事件提供了相應的操作服務，把事件轉化成對模型或相關視圖的激發操作。
如果控制器的行為依賴於模型的狀態，則控制器應該在變化-傳播機制中進行註冊，並提供一個更新操作。這樣，可以由模型的變化來改變控制器的行為，如禁止某些操作。
3 MVC的實現
3.1 分析應用問題，對系統進行分離
分析應用問題，分離出系統的內核功能、對功能的控制輸入、系統的輸出行為三大部分。設計模型部件使其封裝內核數據和計算功能，提供訪問顯示數據的操作，提供控制內部行為的操作以及其他必要的操作接口。以上形成模型類的數據構成和計算關係。這部分的構成與具體的應用問題緊密相關。
3.2 設計和實現每個視圖
設計每個視圖的顯示形式，它從模型中獲取數據，將它們顯示在屏幕上。
3.3 設計和實現每個控制器
對於每個視圖，指定對用戶操作的響應時間和行為。在模型狀態的影響下，控制器使用特定的方法接受和解釋這些事件。控制器的初始化建立起與模型和視圖的聯繫，並且啟動事件處理機制。事件處理機制的具體實現方法依賴於界面的工作平臺。
3.4 使用可安裝和卸載的控制器
控制器的可安裝性和可卸載性，帶來了更高的自由度，並且幫助形成高度靈活性的應用。控制器與視圖的分離，支持了視圖與不同控制器結合的靈活性，以實現不同的操作模式，例如對普通用戶、專業用戶、或不使用控制器建立的只讀視圖。這種分離還為在應用中集成新的I/O設備提供了途徑。
4 MVC的變化
把模型、視圖、控制器實行分離，使設計和使用有了很大靈活性。但是，在現實中，視圖和控制器的功能通常是緊密地聯繫在一起的。控制視圖工作的輸入事件通常都是與視圖的構成相關的。在現實界面設計環境中，界面操作事件及其處理都是與界面形式設計緊密關聯的。在這種情況下，把視圖和控制器分離開，就給分析和設計帶了了不方便，並且運行的效率低。
因此，可以把視圖和控制器結合起來加以設計和實現。在上面的實現說明中，只要把視圖和控制器的類合併生成新的視圖類即可。這樣，仍然保持著與模型的分離，因此相同的模型仍然可以使用多個視圖。這些視圖本身已經具備了事件處理能力，仍然可以通過模型對其功能進行控制。
5 MVC的優點及不足之處
5.1 MVC的優點
MVC的優點表現在以下幾個方面：
（1） 可以為一個模型在運行時同時建立和使用多個視圖。變化-傳播機制可以確保所有相關的視圖及時得到模型數據變化，從而使所有關聯的視圖和控制器做到行為同步。
（2） 視圖與控制器的可接插性，允許更換視圖和控制器對象，而且可以根據需求動態的打開或關閉、甚至在運行期間進行對象替換。
（3） 模型的可移植性。因為模型是獨立於視圖的，所以可以把一個模型獨立地移植到新的平臺工作。需要做的只是在新平臺上對視圖和控制器進行新的修改。
（4） 潛在的框架結構。可以基於此模型建立應用程式框架，不僅僅是用在設計界面的設計中。
5.2 MVC的不足之處
MVC的不足表現在以下幾個方面：
（1） 增加了系統結構和實現的複雜性。對於簡單的界面，嚴格遵循MVC，使模型、視圖與控制器分離，會增加結構的複雜性，並可能產生過多的更新操作，降低運行效率。
（2） 視圖與控制器間的過於緊密的連接。視圖與控制器是相互分離，但確實聯繫緊密的部件，視圖沒有控制器的存在，其應用是很有限的，反之亦然，這樣就妨礙了他們的獨立重用。
（3）視圖對模型數據的低效率訪問。依據模型操作接口的不同，視圖可能需要多次調用才能獲得足夠的顯示數據。對未變化數據的不必要的頻繁訪問，也將損害操作性能。
（4） 目前，一般高級的界面工具或構造器不支持MVC模式。改造這些工具以適應MVC需要和建立分離的部件的代價是很高的，從而造成使用MVC的困難。
6 其他類似的模式
類似的結構模式還有PAC（Presentation-Abstraction-Control）、Forward-Receiver、Publisher-Subscriber、各類可視化用戶界面控制項等。
其中，"表示-抽象-控制"結構模式（PAC）也是從數據模型及其可是化關係的處理上提出的。其中，表示與視圖對應，抽象與模型對應，控制與控制對應。從邏輯本質上，兩者沒有太大區別。但是，MVC和PAC還是存在著不同的地方。
（1） MVC的控制更側重於在視圖上的用戶的I/O處理，而PAC的控制主要指從抽象到表示的傳遞和協調作用。
（2） 此外，PAC把系統分割為協作但鬆散耦合的智能體，而MVC是專門處理交互界面的，各個部件之間的關聯更密切一些。
（3） 另外，從體系結構上看，PAC是屬於系統級別的，因為它解決的問題更傾向於系統及部件之間的協作和關聯關係。
7 小結
與軟體所處理問題的內在模型相比較，用戶界面是需要經常發生變化的，採用MVC設計模式可以在滿足對界面要求的同時，使軟體的計算模型獨立於界面的構成。本文首先介紹了MVC的三個組成構件（模型構件、視圖構件和控制構件），以及實現基於MVC的應用需要完成的工作；接著，對MVC的優點及不足之處進行了分析；最後，介紹了幾種其他類似的結構模式，並對MVC和PAC進行了比較。