三層結構與MVC模式的區別

首先N層結構是一種軟件抽象的層次結構,是對複雜軟件的一種縱向切分,每一層次中完成同一類型的操作,以便將各種代碼以其完成的使命作爲依據來分割,以將低軟件的複雜度,提高其可維護性。一般來說,層次之間是向下依賴的,下層代碼未確定其接口(契約)前,上層代碼是無法開發的,下層代碼接口(契約)的變化將使上層的代碼一起變化。三層結構是N層結構的一種,是人產在長時間使用中得出來的一種應用場合廣泛的N層結構,被當作一種典型的軟件層次結構而廣爲流傳甚至寫入教科書。
    MVC模式是一種複合設計模式,一種在特定場合用於解決某種實際問題來得出的可以反覆實踐的解決方案。巧合的是他也有三個事物組成,於是乎人們就有了一種想當然的對應關係:展示層-View;業務邏輯層-Control;持久層-Model。首先MVC中的三個事物之間並不存在明顯的層次結構,沒有明顯的向下依賴關係,相反的,View和Model往往是比較獨立的,而Control是連接兩者的橋樑,他們更像是橫向的切分。這樣一來就出現一個結果,MVC中每個塊都是可以獨立測試的,而三層結構中,上層模塊的運行測試勢必要提供下層代碼或者提供相同接口的樁。相對來說,MVC複雜得多,但是結構更清晰,耦合性更低。
    另外,MVC中每一塊內部特別是Model內部經常被設計爲多層的。在我認爲的一個良好的MVC模式構建的結構中,Control是核心,小且較爲穩定的,可以作爲一個核心框架來提供,有擴展點,但基本上可以簡單配置不需要任何代碼就可以運行。而View則可能是一套或多種可選擇的視圖引擎,決定了軟件展示給用於的界面,使用時的主要工作量在於擴展點以及根據需要而數量不同的視圖模板。Model則是業務提供者,決定了軟件提供的功能,其內部可能是一些普通的類或者是實現了某些接口的類,在這一塊當中可能根據業務的不同而色彩繽紛,對於複雜的軟件可能會分成很多層,如業務邏輯層、業務提供層、系統提供層、數據提供層、數據訪問層等。
    我經常用於比喻MVC的例子是小時候玩的那種卡帶式遊戲機,Control是主機,一般來說我買一個主機就行了,只要他不壞,他就能一直讓我玩這一類的遊戲。View則是電視機和遊戲手柄,電視機可以獨立工作,他不管輸入的是電視信號、影碟機信號還是遊戲機信號,他只管顯示,而且他決定了我們看到的效果是怎麼樣的,如果我想要個尺寸更大的或者彩色的顯示效果,我只需要買個相應的電視機就行了,手柄也是可以換的,要遙杆還是帶震動的。Model則是遊戲卡帶,他絕定了我玩的是什麼遊戲,是魂鬥羅還是超級瑪莉,而且遊戲機主機和電視機生產廠家永遠也不知道在上面有可能會運行什麼樣的遊戲。卡帶中可能會有遊戲代碼和存儲單元,都根據遊戲的需要而設計。

===================4/30補充==================
  有朋友提到遊戲主機提供的卡帶插槽的接口,在設計中,有時也由Control提供一組接口,以用於Model或View的實現,這樣就形成了依賴。一般來說這樣設計也沒有太大的問題,只是會提高模塊間的耦合度,也會帶來一些侵入性。爲了更完美,可以不用接口來提供契約,可以用配置信息(或稱元數據信息)+反射來提供契約,那麼這個類接口就可以退化到只要符合CLS就可以了,也就是普通的類,就像現在的計算機接口廣泛採用USB,無論是U盤、打印機、掃描儀或者是加密狗,他們都是普通的USB設備而已。
  提到USB有一個題外話,模塊的可插拔性設計甚至是熱插拔設計,系統可以在不停止運行的情況下動態的掛載或移除模塊,動態掛載模塊需要系統能夠自動發現新模塊並根據自描述的信息進行自動配置,移除可能情況更復雜一點,需要“安全刪除硬件”類似的功能。
  在設計廣泛重用的框架時會考慮多種情況以達到更大的適應性,一般項目中應用MVC模式可以較爲隨意。
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章