初始MVC架構和MVVM架構

一、解析MVC架構：

M：Model，資料模型，比如我們人類有一雙手，一雙眼睛，一個腦袋，沒有尾巴，這就是模型，Model定義了這個子產品的資料模型。在代碼中展現為資料管理者，Model負責對資料進行擷取及存放。資料不可能憑空生成的，要麼是從伺服器上面擷取到的資料，要麼是本地資料庫中的資料，也有可能是使用者在UI上填寫的表單即将上傳到伺服器上面存放，是以需要有資料來源。既然Model是資料管理者，則自然由它來負責擷取資料。Controller不需要關心Model是如何拿到資料的，隻管調用就行了。資料存放的地方是在Model，而使用資料的地方是在Controller，是以Model應該提供接口供controller通路其存放的資料（通常通過.h裡面的隻讀屬性）。

V：View，視圖，簡單來說，就是我們在界面上看見的一切。大多數情況都是繼承自UIView的類的對象，而有時候則不是直接繼承自UIView，有時候會直接用CoreAnimation甚至CoreGraphics來繪制内容，但這些東西統統都歸結為MVC中的View。它們有一部分是我們UI定死的，也就是不會根據資料來更新顯示的，比如一些Logo圖檔啊，這裡有個按鈕啊，那裡有個輸入框啊，一些顯示特定内容的label啊等等；有一部分是會根據資料來顯示内容的，比如tableView來顯示好友清單啊，這個tableView的顯示内容肯定是根據資料來顯示的。我們使用MVC解決問題的時候，通常是解決這些根據資料來顯示内容的視圖。這裡要提個醒：MVC雖然看似把子產品分為了三部分，但是并不是說一個子產品就要一定建三個類出來，比如聯系人清單（ContactsList）子產品，一定會有的肯定是ContactsListViewController，然後我們使用MVC來作為内部的架構，則需要建立ContactsListModel類，接下來會有少年繼續建立ContactsListView，他認為這才是MVC，有三個類分别是XXXModel、XXXController、XXXView，這就大錯特錯了，你們在Controller中使用的UILabel、UITableView等等就是MVC中的View了，不要再專門建一個XXXXView出來，完全是沒事找事多此一舉。

C：Controller，最熟悉卻又最抽象的一個東西。之是以熟悉，我們在使用UIKit進行開發中我敢說是你打交道最多的類：UIViewController。UIKit架構離不開UIViewController，當然你完全可以使用UIView來完成所有本該由Controller完成的事情，這是大逆不道的，因為這樣做将會使你的整個項目代碼一團糟，并且完美的違背了面向對象的思想：各司其職。這裡大家一定要知道UIViewController究竟應該做些什麼事，實際上就是API提供出來的接口：self.view用來作為所有視圖的容器；管理自己的生命周期；controller之間的轉場；controller容器。這是Controller的本職工作，然而它往往還需要承擔起MVC中的資料和視圖的協調者，也就是在Controller裡面把Model的資料指派給View來顯示（或者是View接收使用者輸入的資料然後由Controller把這些資料傳給Model來儲存到本地或者上傳到伺服器）。

如果還是不懂的話，上一張坦福大學公開課上的這幅圖來說明，這可以說是最經典和最規範的MVC标準

有駕照的人都不陌生吧？有實線、虛線還有黃線！

看到M(Model)和V(View)之間的黃線了沒有，兩者不能直接溝通，要是溝通了那擴充性不久差了，複用性就降低了。不是我們的初衷，是以就誕生了C(Comtrller)，而C又能同時和M和V溝通，你M中資料一改我C就告訴V讓V也該，反過來也一樣，這樣就實作了資料同步。

綜上所述：大家一般可以這樣了解

（1）M：負責管理資料(從伺服器請求過來的資料或者V中使用者傳回過來的資料都是放在M這裡)。

（2）V：負責顯示資料(使用者看得到的界面)。

（3）C：負責把M中得到得資料指派給V(或把V中得到的資料指派給M)實作資料綁定，同步更新。

二、解析MVVM架構

MVVM含義：

（1）M：還是原來的M，專門搞資料管理的。

（2）V：還是原來的V，專門顯示資料的。

（3）VM：翻譯為View Model，專門來幫助C(Contrller)來解析資料的，并且解析資料完成後再把資料傳給C(Contrller)。

而到這裡可能就有人有疑問了，我那個C(controller)到哪去了？按理來講不應該讀作MVCVM架構嗎？我C(controller)掉廁所了？當然不是，且聽我慢慢道來，但是在此之前大家先記住一個重要結論:

C的存在感因VM的出現變得非常小非常小！！！

C的存在感因VM的出現變得非常小非常小！！！

C的存在感因VM的出現變得非常小非常小！！！

好了，接下裡終于到了解析MVVM了，開森!

按标準的MVC架構來講，M負責管理資料，V負責顯示資料，C負責指派操作，但是這裡有個問題，當C像M索要資料指派給V時，出現了一個問題，假如C向M索要一個叫name=“張三”的資料時，而這個資料是存放在一個名叫obj中某個key值=“names”的數組當中的，那麼這個解析過程(C向M拿到這個資料的過程)預設就由C來做了，這顯然讓C的工作量大大增加，顯得臃腫，并且我C的本意隻是做指派操作的，為啥還要把解析資料這個過程塞給我。是以C理應不該做這件事，而M和V更不該了，它們倆都要分層工作的，不能各自摻雜一些别的東西在裡面。那麼這件事該怎麼做呢？這簡單啊，根據面向對象的思想，你們都不做那麼我再建立一個類來做不就得了？于是，VM就此誕生了(祝賀)！

了解VM誕生的原因，回歸前面，為什麼叫MVVM架構，我C呢？

那麼C的存在感為什麼會變小呢？讀懂了上一段話我們可以了解，原來是因為在MVC架構中，本來向M存取資料操作并且指派給V和解析資料是由C做的，而為了減輕C的負擔，就把解析資料分給了新來的兄弟VM做了。明白這樣一個過程那麼我們可不可以這樣想:C向M請求資料的時候，C不關心這個資料結果是什麼東西，我隻負責從VM兄弟這裡拿到解析的資料就可以了，這樣C不就和M脫離關系了嗎？使得C回歸它的本質（隻給V和M做指派操作）。那我們再來分析VM和M的關系:當C向M請求資料時，M會把資料傳遞給VM進行解析，VM解析完成後直接拿給C，這個過程就完成了。分析：根本就不需要C參與資料的解析操作，說得更明白一點（我C都不需要知道你M的存在，反正我隻負責從我兄弟VM那裡拿到資料，至于有沒有那是VM的事兒）。那麼總結起來就是:C不需要知道M的存在，而M也不需要知道C的存在，因為它們倆互相知道也沒啥意義（莫非你們倆互相知道過後難道能使傳輸資料加快？），并且MVC架構最初的設定各幹各的，互不幹擾。是以MVVM理應如此。

最後再總結一下:

C隻需持有VM，VM隻需持有M。

本文如有錯誤請各位指正，來自一個前端小白對MVC和MVVM的一些淺知識。