MVC設計模式的介紹

繼續程式入門介紹系列，這次來說一下稍微複雜的東西。

一、Unity項目使用架構有什麼好處

以前有段時間我很喜歡在qq群裡面回答問題，後來漸漸的也沒太多時間回答了，是以變成了偶然看看别人讨論的過程。我後來發現，很多朋友都隻是注重功能的實作，當實作了某個功能之後，就很高興，覺得自己已經達到了一定的水準了。甚至有朋友直接的說，我能實作功能就夠了，用Unity開發根本不需要用什麼架構。

出現這種思想，我覺得有很大一部分原因是Unity官方造成的。因為Unity引擎在剛推出來的時候，宣傳的是元件拼裝的思想，而大部分demo都是針對某個具體功能展示而制作的。

所謂的元件拼裝思想，就是我有一個空的GameObject，隻帶了最基本的Transform元件，可以控制位移旋轉縮放。如果使用者需要在上面添加功能，就可以添加相應的元件。比如我需要把一個空物體變成錄影機，隻需要在空物體上面添加Camera元件，如果想這個錄影機同時有碰撞的功能，就再在上面加多個Collider碰撞元件，如果想這個物體順便會發光，那就再添加一個Light的元件。假如需要更複雜的功能，可以自己寫一個繼承MonoBehaviour的腳本挂上去，因為MonoBehaviour腳本對于Unity來說也是一種元件。這樣使用者就可以抛棄面向對象的子類繼承基類之類的繁瑣結構，直接通過編輯器界面實作各種自由的功能。

是以，Unity引擎剛推出來的時候是偏向于給美術和策劃用的，很多所見即所得的功能讓你很簡單就能實作想要的功能，很适合做規模較小的獨立遊戲。是以在這個階段，Unity的确用不用架構好像沒多大的差別。

但随着Unity的快速興起，很多廠商開始拿Unity來做一些大型的項目。這個時候，很明顯單一的功能實作已經不能滿足項目的需要了。因為大型項目一般不會為某個功能的實作而發愁，更注重的是項目的清晰、易于維護和擴充等問題。由于有規模的項目都是多人協助一起寫的，是以更需要注意項目代碼的結構和品質。

好的代碼标準，一般來說是高内聚，低耦合。我們需要把功能分離，讓各人寫的代碼互不影響又能互相支援，可以單獨的修改或者維護某一部分的代碼而不影響到其他功能，代碼可以重複利用，等等。為了達到這些目的，我們會使用一些設計模式，設計遊戲的架構。

MVC是解決這個問題比較常見的一種設計模式，它不是一個具體的架構，而是一種設計的思想。可以根據這種設計的思想，寫出适合項目用的架構。

二、MVC設計模式的特點

舉一個稍微具體一點的例子來說明，我們現在需要做一個功能，可以在界面上面輸入新增使用者資料，然後清單顯示出來。

如果是最簡單的實作，我們可以隻建立一個類，然後寫代碼實作三部分功能：

1、建立一個List來存儲使用者資料。

2、在類裡面繪制一個顯示清單來顯示現有的使用者資料，并繪制一個輸入框和一個按鈕來新增使用者資料。

3、寫一個添加使用者資料的方法，把輸入框的内容添加到使用者資料的List。

這樣就把這個功能實作了。但假如我需要對需求做一些改變，比如我需要修改一下顯示清單的位置和大小，或者我需要給資料存儲加一個防止重複的功能，或者這個使用者資料需要在其他功能也用到。在需求變動的情況下，這個類本身就需要不停的改變。等功能複雜到一定程度之後，這個類可能就會非常臃腫而難于維護了。

為了解決這個問題，我們可以嘗試着把這個類拆分一下。

我們把一個類拆成三個類，分别是view類、model類和controller類。

view類裡面寫了現實清單的繪制方法，還有輸入框和按鈕的繪制。可以通過事件通知它資料改變而重新整理界面上的資料顯示。

model類裡面寫了使用者資料的存儲List，提供查詢方法，還有資料變化時向外抛事件通知别人。

controller類裡面寫了按鈕觸發的方法，可以把view類輸入的新增使用者寫到model裡面。

這樣分割了之後，某些功能相對的就穩定下來了。當我隻需要調整界面外觀時，我可以單獨的修改view類，其他功能想使用使用者資料，可以直接通路model類取得，而需要對操作過程加特殊的方法，隻需要單獨的修改controller類。另外一個好處是，這樣在其他層面的邏輯還沒寫好之前，單獨的層面就可以先編寫。比如我還沒确定這個界面樣式是怎樣擺放的，但我可以先把控制層和資料層寫好，等顯示界面層做好了之後，接入一下就行了。

MVC全名是Model View Controller，是模型(model)－視圖(view)－控制器(controller)的縮寫。一般的了解model層是資料的存儲，view是界面的展示，controller是控制輸入邏輯。

上面這個例子簡單了介紹了MVC模式的工作原理，核心的思想就是，把功能分層，特别是把顯示和資料分開，然後用另外一個層級讓它們2個層級聯合起來工作。

三、MVC模式的進化

MVC的确是現階段廣泛應用的一個設計模式，有很多使用這個模式寫的架構。在使用過程中，會根據一些實際的情況去修改一些結構上的東西。

比如，MVC雖然是把功能分層了，但從最傳統的MVC結構來說，View層是可以通路Model層的，比如View層可以直接去Model層查詢資料并重新整理自己的界面。這個時候，會發現三個層面是形成了一種三角的關系，有時候會存在需要同時維護三個層面的邏輯互動關系。

于是，後來MVC發展出了MVP(Model-View-Presenter)模式。這個模式裡面，切斷了Model層和View層的關聯，view層隻和Presenter層互動，再通過Presenter層和Model層互動。

這樣，Model和View層就完全切斷了關聯，大部分的邏輯實作出現在Presenter層裡面。而Presenter層通過向View層提供接口方法，實作了資料的查詢和重新整理等功能。這樣做之後，當某個層面出現了修改的需要，他都隻需要和Presenter層互動，是以不需要影響到另外一個層面。

MVC模式發展的另外一個方向，是MVVM(Model-View-ViewModel)。這裡提出了一個叫做ViewModel的層面，一個View的類，一般會對應一個單獨的ViewModel類，這個類完全為對應的View類服務，包括了View上面每一個顯示資料的重新整理顯示、輸入邏輯等等。然後ViewModel類再和Model類做互動。這樣的情況下，在沒有View類的情況下，ViewModel類已經完全可以實作了所有功能，隻是沒有把界面繪制出來而已。當有了View類，資料自然而然就會顯示在界面上面了。

MVVM模式的2點比較突出的優點，第一是資料綁定，通過ViewModel層自動更新View層和Model層。第二是可以做界面功能的自動測試。因為在完全不需要顯示View顯示的情況下，通過調用ViewModel提供的各種接口，你等于已經完整的操作這個界面了。

四、一些個人看法

上面說了這麼多MV什麼的模式，估計都看懵了吧？實際上不管是MV什麼，表達的核心思想都是一樣的，顯示層和資料層必須分離，然後第三層的作用都是用于溝通這兩個層的。至于在實際應用中他們的關聯互動程度應該具體怎樣寫，還是需要看你對這些設計模式的了解，還有你項目的具體需要。

對于新手來說，起碼能有分層的概念，先可以看懂别人的架構結構。然後在使用别人的架構做功能的時候，可以根據分層的思想，把代碼集中在對應的層面去編寫。最後，在學習了現有的架構的寫法之後，可以嘗試着自己去寫一些簡單的架構，再一步一步的完事，就可以擁有一套屬于自己的架構了。