淺談三層結構與MVC模式的區別
51CTO編輯推薦《ASP.NET MVC框架視頻教程》
有朋友談到三層與MVC的區別，以前也有人拋出這個問題，本人對來公司面試的朋友也偶樂會提這方面的問題。
那么我也來講講我對這兩者的理解吧。
首先對這個題目，本身是存在問題的，“XX結構”與“XX模式”的區別？請問中國社會制度與美國人生活方式有什么區別？
這兩者本身講的是不同方向與角度的問題，在實際應用中他們的確存在一些相似的特點，在很多書籍中也沒有深入講解，以致于造成困惑，為了更好的理解他們，姑且來說說區別吧。
首先N層結構是一種軟件抽象的層次結構，是對復雜軟件的一種縱向切分，每一層次中完成同一類型的操作，以便將各種代碼以其完成的使命作為依據來分割，以將低軟件的復雜度，提高其可維護性。一般來說，層次之間是向下依賴的，下層代碼未確定其接口（契約）前，上層代碼是無法開發的，下層代碼接口（契約）的變化將使上層的代碼一起變化。三層結構是N層結構的一種，是人產在長時間使用中得出來的一種應用場合廣泛的N層結構，被當作一種典型的軟件層次結構而廣為流傳甚至寫入教科書。
MVC模式是一種復合設計模式，一種在特定場合用于解決某種實際問題來得出的可以反復實踐的解決方案。巧合的是他也有三個事物組成，于是乎人們就有了一種想當然的對應關系：展示層-View；業務邏輯層-Control；持久層-Model。首先MVC中的三個事物之間并不存在明顯的層次結構，沒有明顯的向下依賴關系，相反的，View和Model往往是比較獨立的，而Control是連接兩者的橋梁，他們更像是橫向的切分。這樣一來就出現一個結果，MVC中每個塊都是可以獨立測試的，而三層結構中，上層模塊的運行測試勢必要提供下層代碼或者提供相同接口的樁。相對來說，MVC復雜得多，但是結構更清晰，耦合性更低。
另外，MVC中每一塊內部特別是Model內部經常被設計為多層的。在我認為的一個良好的MVC模式構建的結構中，Control是核心，小且較為穩定的，可以作為一個核心框架來提供，有擴展點，但基本上可以簡單配置不需要任何代碼就可以運行。而View則可能是一套或多種可選擇的視圖引擎，決定了軟件展示給用于的界面，使用時的主要工作量在于擴展點以及根據需要而數量不同的視圖模板。Model則是業務提供者，決定了軟件提供的功能，其內部可能是一些普通的類或者是實現了某些接口的類，在這一塊當中可能根據業務的不同而色彩繽紛，對于復雜的軟件可能會分成很多層，如業務邏輯層、業務提供層、系統提供層、數據提供層、數據訪問層等。
我經常用于比喻MVC的例子是小時候玩的那種卡帶式游戲機，Control是主機，一般來說我買一個主機就行了，只要他不壞，他就能一直讓我玩這一類的游戲。View則是電視機和游戲手柄，電視機可以獨立工作，他不管輸入的是電視信號、影碟機信號還是游戲機信號，他只管顯示，而且他決定了我們看到的效果是怎么樣的，如果我想要個尺寸更大的或者彩色的顯示效果，我只需要買個相應的電視機就行了，手柄也是可以換的，要遙桿還是帶震動的。Model則是游戲卡帶，他絕定了我玩的是什么游戲，是魂斗羅還是超級瑪莉，而且游戲機主機和電視機生產廠家永遠也不知道在上面有可能會運行什么樣的游戲?？◣е锌赡軙杏螒虼a和存儲單元，都根據游戲的需要而設計。
有朋友提到游戲主機提供的卡帶插槽的接口，在設計中，有時也由Control提供一組接口，以用于Model或View的實現，這樣就形成了依賴。一般來說這樣設計也沒有太大的問題，只是會提高模塊間的耦合度，也會帶來一些侵入性。為了更***，可以不用接口來提供契約，可以用配置信息（或稱元數據信息）+反射來提供契約，那么這個類接口就可以退化到只要符合CLS就可以了，也就是普通的類，就像現在的計算機接口廣泛采用USB，無論是U盤、打印機、掃描儀或者是加密狗，他們都是普通的USB設備而已。
提到USB有一個題外話，模塊的可插拔性設計甚至是熱插拔設計，系統可以在不停止運行的情況下動態的掛載或移除模塊，動態掛載模塊需要系統能夠自動發現新模塊并根據自描述的信息進行自動配置，移除可能情況更復雜一點，需要“安全刪除硬件”類似的功能。
在設計廣泛重用的框架時會考慮多種情況以達到更大的適應性，一般項目中應用MVC模式可以較為隨意。
【編輯推薦】
