iOS面試題：MVVM和MVC的區別

MVVM和MVC的區別

1. MVC

MVC的弊端

• 厚重的View Controller
• M：模型model的對象一般很是的簡單。根據Apple的文檔，model應包括數據和操做數據的業務邏輯。而在實踐中，model層每每很是薄，無論怎樣，model層的業務邏輯不該被拖入到controller。
• V：視圖view一般是UIKit控件（component，這裏根據習慣譯爲控件）或者編碼定義的UIKit控件的集合。View的如何構建（PS：IB或者手寫界面）何須讓Controller知曉，同時View不該該直接引用model（PS：現實中，你懂的！），而且僅僅經過IBAction事件引用controller。業務邏輯很明顯不納入view，視圖自己沒有任何業務。
• C：控制器controller。Controller是app的「膠水代碼」：協調模型和視圖之間的全部交互。控制器負責管理他們所擁有的視圖的視圖層次結構，還要響應視圖的loading、appearing、disappearing等等，同時每每也會充滿咱們不肯暴露的model的模型邏輯以及不肯暴露給視圖的業務邏輯。網絡數據的請求及後續處理，本地數據庫操做，以及一些帶有工具性質輔助方法都加大了Massive View Controller的產生。
• 遺失（無處安放）的網絡邏輯 蘋果使用的MVC的定義是這麼說的：全部的對象均可以被歸類爲一個model，一個view，或是一個controller。

你可能試着把它放在Model對象裏，可是也會很棘手，由於網絡調用應該使用異步，這樣若是一個網絡請求比持有它的model生命週期更長，事情將變的複雜。顯然View裏面作網絡請求那就更格格不入了，所以只剩下Controller了。若這樣，這又加重了Massive View Controller的問題。若不這樣，何處纔是網絡邏輯的家呢？

• 較差的可測試性

因爲View Controller混合了視圖處理邏輯和業務邏輯，分離這些成分的單元測試成了一個艱鉅的任務。

2. MVVM

一種能夠很好地解決Massive View Controller問題的辦法就是將 Controller 中的展現邏輯抽取出來，放置到一個專門的地方，而這個地方就是 viewModel 。MVVM衍生於MVC，是對 MVC 的一種演進，它促進了 UI 代碼與業務邏輯的分離。它正式規範了視圖和控制器緊耦合的性質，並引入新的組件。他們之間的結構關係以下：

2.1 MVVM 的基本概念

• 在MVVM 中，view 和 view controller正式聯繫在一塊兒，咱們把它們視爲一個組件
• view 和 view controller 都不能直接引用model，而是引用視圖模型（viewModel）
• viewModel 是一個放置用戶輸入驗證邏輯，視圖顯示邏輯，發起網絡請求和其餘代碼的地方
• 使用MVVM會輕微的增長代碼量，但整體上減小了代碼的複雜性

2.2 MVVM 的注意事項

• view 引用viewModel ，但反過來不行（即不要在viewModel中引入#import UIKit.h，任何視圖自己的引用都不該該放在viewModel中）（PS：基本要求，必須知足）
• viewModel 引用model，但反過來不行* MVVM 的使用建議
• MVVM 能夠兼容你當下使用的MVC架構。
• MVVM 增長你的應用的可測試性。
• MVVM 配合一個綁定機制效果最好（PS：ReactiveCocoa你值得擁有）。
• viewController 儘可能不涉及業務邏輯，讓 viewModel 去作這些事情。
• viewController 只是一箇中間人，接收 view 的事件、調用 viewModel 的方法、響應 viewModel 的變化。
• viewModel 絕對不能包含視圖 view（UIKit.h），否則就跟 view 產生了耦合，不方便複用和測試。
• viewModel之間能夠有依賴。
• viewModel避免過於臃腫，不然重蹈Controller的覆轍，變得難以維護。

2.3 MVVM 的優點

• 低耦合：View 能夠獨立於Model變化和修改，一個 viewModel 能夠綁定到不一樣的 View 上
• 可重用性：能夠把一些視圖邏輯放在一個 viewModel裏面，讓不少 view 重用這段視圖邏輯
• 獨立開發：開發人員能夠專一於業務邏輯和數據的開發 viewModel，設計人員能夠專一於頁面設計
• 可測試：一般界面是比較難於測試的，而 MVVM 模式能夠針對 viewModel來進行測試

2.4 MVVM 的弊端

• 數據綁定使得Bug 很難被調試。你看到界面異常了，有多是你 View 的代碼有 Bug，也多是 Model 的代碼有問題。數據綁定使得一個位置的 Bug 被快速傳遞到別的位置，要定位原始出問題的地方就變得不那麼容易了。
• 對於過大的項目，數據綁定和數據轉化須要花費更多的內存（成本）。主要成本在於：
• 數組內容的轉化成本較高：數組裏面每項都要轉化成Item對象，若是Item對象中還有相似數組，就很頭疼。
• 轉化以後的數據在大部分狀況是不能直接被展現的，爲了可以被展現，還須要第二次轉化。
• 只有在API返回的數據高度標準化時，這些對象原型（Item）的可複用程度才高，不然容易出現類型爆炸，提升維護成本。
• 調試時經過對象原型查看數據內容不如直接經過NSDictionary/NSArray直觀。
• 同一API的數據被不一樣View展現時，難以控制數據轉化的代碼，它們有可能會散落在任何須要的地方。

3. 總結

• MVC的設計模式也並不是是病入膏肓，無藥可救的架構，最起碼目前MVC設計模式仍舊是iOS開發的主流框架，存在即合理。針對文章所述的弊端，咱們依舊有許多可行的方法去避免和解決，從而打造一個輕量級的ViewController。
• MVVM是MVC的升級版，徹底兼容當前的MVC架構，MVVM雖然促進了UI 代碼與業務邏輯的分離，必定程度上減輕了ViewController的臃腫度，可是View和ViewModel之間的數據綁定使得 MVVM變得複雜和難用了，若是咱們不能更好的駕馭二者之間的數據綁定，一樣會形成Controller 代碼過於複雜，代碼邏輯不易維護的問題。
• 一個輕量級的ViewController是基於MVC和MVVM模式進行代碼職責的分離而打造的。MVC和MVVM有優勢也有缺點，但缺點在他們所帶來的好處面前時不值一提的。他們的低耦合性，封裝性，可測試性，可維護性和多人協做便利大大提升了開法效率。
• 同時，咱們須要保持的是一個擁抱變化的心，以及理性分析的態度。在新技術的面前，不盲從，也不守舊，一切的決策都應該創建在認真分析的基礎上，這樣才能應對技術的變化。

更多：iOS面試題合集