像名片、日程、任務、短信、文件浏覽器和多媒體播放器等應用程序，都采用MVC模型作為其基本架構。但從這段時間的文檔評審來看，我們對MVC模型的理解仍然存在一些誤區。這裡簡單談一談，歡迎交流。
先說兩句題外話，免得少數網友替我著急。他們會說，拜托，你寫點新內容好不好，不要用MVC這類老掉牙的東西來充數。呵，很多人都熱衷於新技術，我以前也一樣。經過五六年的學習和實踐後，讓人遺憾的是，我沒有發現什麼真正的新技術。相反，倒是一些”老”技術充滿魅力。包括像匯編語言、C/C++、awk/bash、計算機組成原理、操作系統原理、數據庫原理、編譯原理、數據結構、TCP/IP實現、面向對象、設計模式、POSA、代碼重構、自動測試、人機交互，RUP/XP等比較通用的知識，也包括像Linux、apache、xerces/xalan、GTK+/X/glib、STL/boost、MFC、COM/DCOM等這樣特定平台/函數庫。根據自己的經驗來看，了解一項技術的基本內容並不難，難點在於靈活應用它們，在於適當的時候選擇適當的技術。個人認為，把目前這些”老”技術掌握好了，無論是設計還是編程，完全可以做到游刃有余的境界(我還在努力中)。相反，整天只關注所謂的新技術，對一些經典技術反而只了解皮毛，可以說是撿了芝麻丟了西瓜，得不嘗失。道不同不相與謀，熱衷於新技術的朋友可以在此打住了。
好了，言歸正傳。下面是我在我們平台中發現的一些問題：
1. 把控制器(Controller)和模型(Model)混在了一起。MVC模型的三大部分中的控制器(Controller)是最容易讓人混淆的，在基於窗口的GUI應用程序中，控制器(Controller)一般就是控件的事件處理函數。控制器(Controller)有兩個基本功能，一是把用戶從界面上的操作(點擊按鈕)映射成模型(Model)對應的功能(如刪除數據)，二是把模型(Model)的變化更新到視圖(View)上。控制器(Controller)和視圖(View)的耦合比較緊密，盡管可以用策略模式來實現多個控制器(Controller)之間的切換，但那樣做，實現復雜而且沒有多少好處，所以很少有人去分離控制器(Controller)和視圖(VIEw)（據說web開發例外）。然而Glade把產生的事件處理函數放在callbacks.h/.c中，把產生的界面代碼放在interface.h/.c中，這看似把界面與實現分離了，使得一些同事誤以為callbacks.h/.c中的代碼就是模型(Model)，所以把控制器(Controller)和模型(Model)混一起了。結果是模型(Model)包含了一些控件，沒有做到與界面的分離。
2. 所有界面與模型(Model)關聯。有的界面是比較獨立的，完全可以以一種調用關系來實現，結果也與模型(Model)掛了鉤。這看似充分利用了模型(Model)，實際上是把模型(Model)當成了全局變量的替代器。結果是一方面增加了界面與模型(Model)耦合，讓這些獨立的界面難以重用，同時也增加了模型(Model)復雜度。
3. 認為一個應用程序只能有一個模型(Model)。大部分應用程序都只需要一個模型，但一些同事把這個現象這看成了定論。其實模型(Model)是一個邏輯上的概念，如果幾個視圖和另外幾個視圖毫無關聯，最好各自使用獨立的模型(Model)。否則把多個模型(Model)絞在一起，造成不必要的耦合，使用代碼重用困難，也讓增加模型(Model)的復雜度，使實現的難度增加。
4. 認為模型(Model)是一個不可再分的單元。在一些設計中，界面無關的實現代碼的確與界面代碼分開了，但它們都放在模型(Model)裡，模型(Model)成了一個龐然大物。我們說了，模型(Model)只是一個邏輯上的概念，甚至完全可以沒有模型(Model)這個名字出現，其架構仍然是基於MVC的。模型(Model)的責任一般要進一步劃分，把責任分配多個更專業的類上。否則模型(Model)會過於復雜，使實現的難度增加。
