## MVC+MVP+MVVM 項目實例 ## MVC MVC全名 Model View Controller 模型（model）-視圖（view）-控制器（controller） 一種軟件設計典范，用一種業務邏輯、數據、界面顯示分離的方法組織代碼，在改進和個性化定制界面及用戶交互的同時，不需要重新編寫業務邏輯。 - M是指業務模型，處理數據，業務邏輯； - Model 層就是 **JavaBean 實體類**，用于保存實例數據 - 與View無關，而與業務相關，對數據庫的操作、網絡的操作都應該在Model里面處理，當然對業務計算機等操作也是必須放在該層的。就是應用程序中二進制的數據。 - V是指用戶界面 - View 層其實就是程序的 UI 界面，用于向用戶展示數據以及接收用戶的輸入 - Android中，View一般采用XML文件進行界面的描述， - C則是控制器 - Controller 控制器用于更新 UI 界面和數據實例 - Android中Controller重任通常由Activity和Fragment擔當，暗含了不要在Activity中寫代碼，要通過Activity交割Model業務邏輯層處理，另一原因是Android中Activity響應時間是5s，如果耗時操作放在這里，程序很容易被回收掉  - 缺點：Activity既是View又是controller,沒有實現VC的分離、 ## MVP - MVP模式的核心思想 把Activity中的UI邏輯抽象成View接口，把業務邏輯抽象成Presenter接口，Model類還是原來的Model類  - View：負責繪制UI元素，與用戶進行交互（Android中體現為Activity） - Model：負責存儲、檢索、操作數據（有時也實現一個Model interface 用來降低耦合） - Presenter：作為View與Model交互的中間紐帶，處理與用戶交互的負責邏輯 - View interface：需要View實現的接口，View通過View Interface與Presenter進行交互，降低耦合，方便進行單元測試 - **優點**： - 降低耦合度，實現了Model和View真正的完全分離，可以修改View而不影響Model - 模塊職責換分明顯，層次清晰 - 隱藏數據（**Model里面如何操作，View不需要知道，View真正關心的是Model的處理結果**） - Presenter可以復用（比如：多個Activity使用同一個Presenter，ex：登錄注冊可以使用一個Presenter） - 利于測試驅動開發 - View 可以進行組件化 - 代碼靈活性 - Activity只處理生命周期的任務，代碼簡潔 - 視圖邏輯和業務邏輯抽象到了View和Presenter中，提高閱讀性 - Presenter被抽象成接口，可以有多種具體的實現 - 業務邏輯在Presenter中，避免后臺線程引用Activity導致內存泄漏，但是有時候如果Presenter持有view的引用，可是view關閉，也有可能造成Activity的內存泄漏 - **缺點** - Presenter除了對應的應用邏輯之外，還有大量的View-->Model,Model-->View的手動同步邏輯，造成Presenter比較笨重，維護起來會比較困難 - 由于視圖的渲染放在了Presenter中，所以視圖和Presenter的交互會過于頻繁 - 如果Presenter過多地渲染了視圖，往往會使得它與特定的視圖的聯系過于緊密。一旦視圖需要更改，則Presenter也需要更改。 - 額外的代碼復雜度及學習成本 MVP設計原則（常用的） - 一個Activity對應一個View - 通常情況下，一個View對應一個Presenter，在業務復雜時，一個Activity可對應多個Presenter - 將View與Presenter抽象成接口 ### MVC和MVP對比 ###  ### MVP與MVC對比總結 ### - MVC允許View和Model直接通訊 - MVP中，所有對Model的交互都由Presenter內部來完成 - MVP中，View通常會抽象化出來系列的接口（面向接口編程） - MVP相對MVC而言，大大降低了耦合度（Activity不再進行復雜的操作），層級更明顯，更現實單元測試 - MVP的缺點：類文件會越來越來多，會“大爆炸”，有一定的學習成本。