mvc
全稱是 model view controller，是模型 (model)－檢視 (view)－控制器 (controller) 的縮寫。它表示的是一種常見的客戶端軟體開發框架。
現在，mvc 已經成為主流的客戶端程式設計框架，在 ios 開發中，系統為我們實現好了公共的檢視類：uiview，和控制器類：uiviewcontroller。大多數時候，我們都需要繼承這些類來實現我們的程式邏輯，因此，我們幾乎逃避不開 mvc 這種設計模式。
但是，幾十年過去了，我們對於 mvc 這種設計模式真的用得好嗎？其實不是的，mvc 這種分層方式雖然清楚，但是如果使用不當，很可能讓大量**都集中在 controller 之中，讓 mvc 模式變成了 massive view controller 模式。
controller 的臃腫問題何解？
我們來看看 mvc 這種架構的特點。其實設計模式很多時候是為了don't repeat yourself原則來做的，該原則要求能夠復用的**要盡量復用，來保證重用。在 mvc 這種設計模式中，我們發現 view 和 model 都是符合這種原則的。
對於 model 來說，它其實是用來儲存業務的資料的，如果做得好，它也可以方便地復用。比如我當時在做有道雲筆記 ipad 版的時候，我們就直接和 ios 版復用了所有的 model 層的**。在創業做猿題庫客戶端時，ios 和 ipad 版的 model 層**再次被復用上了。當然，因為和業務本身的資料意義相關，model 層的復用大多數是在乙個產品內部，不太可能像 view 層那樣開源給社群。
說完 view 和 model 了，那我們想想 controller，controller 有多少可以復用的？我們寫完了乙個 controller 之後，可以很方便地復用它嗎？結論是：非常難復用。在某些場景下，我們可能可以用addsubviewcontroller之類的方式復用 controller，但它的復用場景還是非常非常少的。
如果我們能夠意識到 controller 裡面的**不便於復用，我們就能知道什麼**應該寫在 controller 裡面了，那就是那些不能復用的**。在我看來，controller 裡面就只應該存放這些不能復用的**，這些**包括：
在初始化時，構造相應的 view 和 model。
監聽 model 層的事件，將 model 層的資料傳遞到 view 層。
監聽 view 層的事件，並且將 view 層的事件**到 model 層。
如果 controller 只有以上的這些**，那麼它的邏輯將非常簡單，而且也會非常短。
但是，我們卻很難做到這一點，因為還是有很多邏輯我們不知道寫在**，於是就都寫到了 controller 中了，那我們接下來就看看其它邏輯應該寫在**。
mvvm
model-view-viewmodel 的簡寫。但在我的理解可以是model-viewmodel-controller-view
為什麼要這樣樣理解呢？上面的問題controller的**處理太多東西，導致極其難復用，而且在後期調整業務，更換ui等事情上也會較為困難。
所以我的建議是將controller的所有業務邏輯都應該移動到viewmodel層上。具體該做些什麼呢？
我們可以將網路請求的藉口，及返回的資料寫在viewmodel裡面，viewmodel再通知controller來取得相應的資料，並顯示在view上。
還可以將邏輯計算等方法封裝在viewmodel裡面，供controller呼叫。當然如果這部分計算復用性很高，你還可以封裝到其他公用的類裡面。
而這個viewmodel將會是乙個隨時可以被其他功能模組呼叫的狀態。而且，乙個controller可以使用乙個或多個viewmodel。這樣將會大大提高**分復用性，及降低後期的維護。
mvvm 在使用當中，通常還會利用雙向繫結技術，使得 model 變化時，viewmodel 會自動更新，而 viewmodel 變化時，view 也會自動變化。而這個過程我們可以使用kvo和notification來實現，但這樣並不是最理想和高效的方式，所以我們需要結合reactivecocoa一起使用。
reactivecocoa是乙個函式式程式設計（functional programming）和響應式程式設計（react programming）庫
函式式程式設計（functional programming），函式也變成一等公民了，可以擁有和物件同樣的功能，例如當成引數傳遞，當作返回值等。看看 swift 語言帶來的眾多函式式程式設計的特性，就你知道這多 cool 了。
響應式程式設計（react programming），原來我們基於事件（event）的處理方式都弱了，現在是基於輸入（在 reactivecocoa 裡叫 signal）的處理方式。輸入還可以通過函式式程式設計進行各種 combine 或 filter，盡顯各種靈活的處理。
無狀態（stateless），狀態是函式的魔鬼，無狀態使得函式能更好地測試。
不可修改（immutable），資料都是不可修改的，使得軟體邏輯簡單，也可以更好地測試。
結合了rac庫，使得我們編寫的程式更加簡潔高效，維護性更高。
總結：
使用mvvm編寫**，雖然使層次增加了，但是提高了**的復用性及提高了**的可維護性，再結合rac就更加牛b閃閃了。你們覺得呢？
Web前端開發 為何選擇MVVM而非MVC
在web中充斥著所謂的mvc框架，而在我看來，因為一些關鍵性的技術原因，mvc在web前端開發中根本無法使用 對的，是無法，而不是不該 在mvc原始報告中指出 view永遠不會知道使用者輸入，比如滑鼠操作和按鍵。很顯然，在web前端，你無法做到這一點，因為web的程式中，使用者的輸入必須通過監聽視窗...
MVC模式 MVVM模式
mvc是一種架構模式，m表示model，v表示檢視view，c表示控制器controller model負責儲存 定義 運算元據 view用於展示介面，與使用者進行操作互動 controller是model和view之間的橋梁，將model中的資料傳遞到view。關係解讀 controller可以直...
MVC 和 MVVM 設計模式
mvc模式 mvc即model view controller。他是1970年代被引入到軟體設計大眾的。mvc模式致力於關注點的切分，這意味著model和controller的邏輯是不與使用者介面 view 掛鉤的。因此，維護和測試程式變得更加簡單容易。mvc設計模式將應用程式分離為3個主要的方面 ...