為什麼MVVM無法拯救你的專案
摘要：
MVVM在MVC的基礎上，增加了一層 ViewModel，目的是為了解決 MVC 架構模式中 ViewController 過於臃腫的問題，基本結構如圖：
MVVM
ViewModel 有以下特點：
ViewModel 持有 Mode...
MVVM在MVC的基礎上，增加了一層 ViewModel，目的是為了解決 MVC 架構模式中 ViewController 過於臃腫的問題，基本結構如圖：
MVVM
ViewModel 有以下特點：
- ViewModel 持有 Model，但不能包含任何UI物件。
- View只處理資料，而不處理UI互動邏輯。
- ViewModel 的獨立性，使得它便於單元測試，也能夠被多個 View（ViewController）複用。
初學者往往將UI物件設計為ViewModel的屬性，甚至還抑制不了在 ViewModel 中處理頁面導航的衝動，結果導致 ViewModel 成為另一個 ViewController，我們知道 ViewController 還處理了如旋轉等裝置事件，結果導致 ViewController 和 ViewModel 緊耦合，上面提到的特點3也就無從談起。
也有很多初學者希望MVVM能減少其開發量，實際上，由於 ViewModel 層是新增加的一層，負責的是 資料加工 ，如字串拼接、資料格式化等工作，並沒有代替 ViewController 管理 View 互動的職責，加上額外的與 ViewModel 互動的工作，程式碼量是增加的，如果開發團隊人力資源有限，專案沒有延續性（一個專案開發的成果很少能延續到下一個專案），是否使用MVVM就需要慎重平衡。
因此 MVVM 既不是更高階的 MVC，也不是iOS開發開發的“銀彈”，就像一家石油公司，在大範圍中運輸中，石油管道有無比優勢，但如果只是將油運到一個農村的農機加油站，小油罐車就變得更有優勢。
思考題：
網路請求一直是導致 ViewController 臃腫的罪魁禍首，MVVM中，應該將網路請求放到哪一層，為什麼？歡迎你的留言。