ACM_Someone like you

 1）Model 和 View 永遠不能相互通信，只能通過 Controller 傳遞。

 2）Controller 可以直接與 Model 對話（讀寫調用 Model），Model 通過 Notification 和 KVO 機制與 Controller 間接通信。

 3）Controller 可以直接與 View 對話，通過 outlet，直接操作 View，outlet 直接對應到 View 中的控件，View 通過 action 向 Controller 報告事件的發生(如用戶 Touch   我了)。Controller 是 View 的直接數據源（數據很可能是 Controller 從 Model 中取得并經過加工了）。Controller 是 View 的代理（delegate)，以同步 View 與 Controller。

4.優點

（1）實現了基本目的：將視圖和數據分離開來，降低藕荷度

  (2)   方便debug調試問題出處是Controller還是View還是Model

5. 缺點

（1）隨著項目的不斷迭代開發，Controller 承擔業務量加大，負擔變重。因此網上提及MVVM好處時候不免都diss一下MVC是“Massive View Controller（重量級視圖控制器）”

（2） 較差的可測試性

（3） 遺失的網絡邏輯 //過重的Controller 被堆砌，很難從堆砌的網絡邏輯中查找對應哪一個具體UI展示的

6.目前，我們做的盡可能給Controller 減負的方式

（1）遵循基本OC編碼規則，明確函數分組和協議實現中使用#pragma mark -來分類方法。好處來說，代碼結構清晰。不論厚重與否，我們都遵循統一編碼規則，從review,迭代的角度，都是相對有利的

  (2) 使用類別category，來管理控制器中的業務，一個業務一個同級別類別category。 例如首頁元素：

•  yiji和起居板塊
•  健康檔案計劃
•  調理方案
•  癥狀
• 文章list

       這些豐富的數據源來一個或者多個接口，UI展示出來有其特有的位置，于是選擇使用類別category的方式來處理。

       注意：使用類別只能離散化代碼，邏輯層面更優秀一些，但不能真正減輕ViewController的負擔。絕對依賴，還是有問題。進一步優化還是值得深挖挖

（3）分離數據源：實現 UITableViewDataSource 代理 協議相關的代碼封裝成一個類。這個我之前寫過一個博客 參考鏈接2。

       注意：這種方法最好是團隊合作在開發上有交集，要絕對大家都知曉你這么做，并能認同這種優化方式，否則一個后果是，別人讀不懂你的代碼，同事又寫了一遍。。。反而這種分離數據源的方法是一種過渡設計了

（4）使用一些優秀第三方減少代碼量

       eg. Masonry:在純代碼手動代碼設置視圖的約束時，優秀得無可挑剔

           YYKit系列:真是業內大牛利用自己學習心得開源出來的，非常牛逼，閱讀一遍源碼，自己再進行開發時候都下筆如有神的感覺。

                          其中YYModel真是比自己寫的那個反射好多了，足夠面向對象，足夠優秀,突然在大神面前感覺自己就是渣渣。繼續努力，保持對學習進步的熱忱之心

（5）尊重面相對象，該封裝的方法，模塊都進行封裝。

       eg.比如AFNetWorking ,做好封裝。把相近業務網絡請求部分放進一個類別里面，在控制器中直接調用我們自己的封裝即可