IOS-淺談MVVM 架構

小編對於MVVM實心得如下：

1.拆解：

M： Model ，包括資料模型、訪問資料庫的操作和網路請求等
V： View ，包括了iOS中的 View 和 controller 組成，負責 UI 的展示，綁定 viewModel 中的屬性,如果在撰寫tableView這些會觸發delegate的東西,把它放在controller就可以了.



VM： ViewModel ，負責從 Model 中獲取 View 所需的資料，轉換成 View 可以展示的資料，並暴露公開的屬性和命令供 View 進行綁定ㄝ,也就是將MVC 上使用邏輯層 controller放在這裡使用.
Binder：這是我最近發現的，在標準MVVM中沒有提到的一部分，但是如果使用MVVM + ReactiveCocoa就會自然地寫出這一層。這一層主要為了實現響應式編程的功能，實現 View 和 ViewModel 的同步或著使用KVO方式.


MVC——>MVVM：

MVC是蘋果官方推薦的開發模式，但是伴隨這這模式產生的問題非常的多，這是隨著項目的逐漸擴大、架構的逐漸復雜顯示出來的，這也是為什麼MVC也被調侃成Massive View Controller（重量級視圖控制器）。大多數情況下，小型項目MVC開發不會帶來太大的負擔，即使你將大量的邏輯代碼（不包括通用的工具類邏輯）放在了ViewController中，但只要該部分由一個人維護，相對來說還是可以保持邏輯清晰的。

但當項目越來越大時，或者一個模塊會有多個人維護時，讀代碼變成了一件非常困難的事，並且，MVC模式的iOS開發一直存在難以測試的問題。iOS開發後，加上公司一直沒有QA，線上發現的BUG簡直就是每天的噩夢。 MVVM帶來的好處是 VM 層可以方便的做測試，因為 VM 層是獨立的邏輯，脫離對 View 和 Model 的依賴。

結論：寫此架構覺得要對此架構相當了解寫會比較好,尤其在團隊合作時,不然一個還在MVC,一個在寫MVVM,之後維護的人看到會相當頭痛,在MVVM上小編覺得使用KVO相當重,但了解MVVM後,會覺得程式分得乾淨,之後維護看的人也會看的很舒服,但此架構可能不是最好的,之後一定還有更厲害的架構 XD.