何為架構？

• 軟件開發中的設計方案。
• 類與類之間的關系、模塊與模塊之間額關系、客戶端與服務端的關系。

經常聽到的架構名詞？

• MVC、MVP、MVVM、VIPER、CDD。
• 三層架構、四層架構。

MVC

Model-View-Controller

• Model：
  模型對象封裝了應用程序的數據，并定義操控和處理該數據的邏輯和運算。例如，模型對象可能是表示商品數據 list。用戶在視圖層中所進行的創建或修改數據的操作，通過控制器對象傳達出去，最終會創建或更新模型對象。模型對象更改時（例如通過網絡連接接收到新數據），它通知控制器對象，控制器對象更新相應的視圖對象。
• View：
  視圖對象是應用程序中用戶可以看見的對象。視圖對象知道如何將自己繪制出來，可能對用戶的操作作出響應。視圖對象的主要目的就是顯示來自應用程序模型對象的數據，并使該數據可被編輯。盡管如此，在 MVC 應用程序中，視圖對象通常與模型對象分離。
  在iOS應用程序開發中，所有的控件、窗口等都繼承自 UIView，對應 MVC 中的 V。UIView 及其子類主要負責 UI 的實現，而 UIView 所產生的事件都可以采用委托的方式，交給 UIViewController 實現。
• Controller：
  在應用程序的一個或多個視圖對象和一個或多個模型對象之間，控制器對象充當媒介。控制器對象因此是同步管道程序，通過它，視圖對象了解模型對象的更改，反之亦然。控制器對象還可以為應用程序執行設置和協調任務，并管理其他對象的生命周期。
  控制器對象解釋在視圖對象中進行的用戶操作，并將新的或更改過的數據傳達給模型對象。模型對象更改時，一個控制器對象會將新的模型數據傳達給視圖對象，以便視圖對象可以顯示它。

MVC

• 優點：View、Model可以重復利用。
• 缺點：Controller的代碼過于臃腫。

MVP

Model View Presenter（模型 視圖 協調器）

• Model：
  數據對象，包含網絡請求，以及數據 SQLite 的 CRUD(增加(Create)、讀取(Retrieve)、更新(Update)和刪除(Delete)) 操作（比如 iOS 平臺，一般以 FMDB 框架直接操作 sql，或者用 CoreData) 。一般可以將數據對象是否需要緩存設計成一個字段 isCache，或者針對整個項目設計一個開存儲關，決定整個項目是否需要數據緩存。我們常見的新聞類 App，在離線的時候看到的數據，都是做了緩存處理的。比如一些金融類的 App，實時性比較高，是不做緩存的。
• View：
  就是 View 的一些封裝、重用。在一款精心設計過的 App 里面，應該有很多 View 是可以封裝重用的。比如一些自己的 TableViewCell，自己設計的 Button，一些 View（包含一些子 View，UI 精心設計過，在項目里多處出現的）等等。

• Presenter：
  只是 Model 層和 View/ViewController層的一個橋梁。Presenter 層就不至于太臃腫，容易看懂。一些大的 App，或因為上線時間比較久了，經歷過眾多程序員的修補，或因前期并未做好架構，以至于打開一個類，幾千行的代碼，看著自己都暈。

  
  
  MVP
• 優點：
  模型與視圖完全分離，我們可以修改視圖而不影響模型
  可以更高效地使用模型，因為所有的交互都發生在一個地方——Presenter內部
  我們可以將一個Presener用于多個視圖，而不需要改變Presenter的邏輯。這個特性非常的有用，因為視圖的變化總是比模型的變化頻繁。
  如果我們把邏輯放在Presenter中，那么我們就可以脫離用戶接口來測試這些邏輯（單元測試）
• 缺點：
  由于對視圖的渲染放在了Presenter中，所以視圖和Persenter的交互會過于頻繁。
  還有一點你需要明白，如果Presenter過多地渲染了視圖，往往會使得它與特定的視圖的聯系過于緊密。一旦視圖需要變更，那么 Presenter也需要變更了。比如說，原本用來呈現Html的Presenter現在也需要用于呈現Pdf了，那么視圖很有可能也需要變更。

MVVM

View、View Model、Model這三部分之間的相互解耦。

• Model：
  與業務和驗證邏輯有關的域模型，都可以認為是MVVM中的Model。比如：業務對象，數據傳輸對象（DTOs），實體，代理對象等等都可以認為是Model。
  這里的Model與MVC中的Model一樣。
• View：
  View負責定義頁面結構，布局用戶在屏幕上看到的界面。在iOS開發中，View一般是程序中的一個頁面。一個View也可以是父View的一部分。
  每個View都有自己的View Model，或者它從父View中繼承了View Model。View通常是通過通過View Model的綁定，或者調用View Model中的方法來獲取數據。在運行的時候，UI控件要響應View Model拋出通知事件，來更新UI。
  為了響應UI上的交互，需要在View Model中實現相應的代碼。比如一個按鈕被點擊。需要將這個按鈕點擊事件綁定到View Model中去。然后在View Model中寫代碼處理用戶的交互。
  在iOS開發中View和ViewController都是屬于View這部分。
• View Model：
  View Model扮演著View和Model的中介角色，它負責處理視圖邏輯和數據轉化。一般來說View Model通過調用Model的方法來和Model進行交互。View Model隨后將從Model中獲取的數據以一種view容易使用的格式提供給View。View Model負責UI交互的響應代碼實現。例如：當用戶點擊了一個按鈕在UI中，這個動作會使得View Model中相應代碼被執行。View Model也負責控制視圖的顯示邏輯，比如修改UI指示操作正在進行。

MVVM

• 優點：
  方便測試 便于代碼的移植。
  兼容MVC。
• 缺點：
  類會增多，ViewModel會越來越龐大，調用復雜度增加。

VIPER

• View（視圖）
  提供完整的視圖，負責視圖的組合、布局、更新
  向Presenter提供更新視圖的接口
  將View相關的事件發送給Presenter
• Presenter（展示器）
  接收并處理來自View的事件
  向Interactor請求調用業務邏輯
  向Interactor提供View中的數據
  接收并處理來自Interactor的數據回調事件
  通知View進行更新操作
  通過Router跳轉到其他View
• Router（路由）
  提供View之間的跳轉功能，減少了模塊間的耦合
  初始化VIPER的各個模塊
• Interactor（交互器）
  維護主要的業務邏輯功能，向Presenter提供現有的業務用例
  維護、獲取、更新Entity
  當有業務相關的事件發生時，處理事件，并通知Presenter
• Entity（實體）
  和Model一樣的數據模型

VIPER

• 優點：
  可測試性好。UI測試和業務邏輯測試可以各自單獨進行。
  易于迭代。各部分遵循單一職責，可以很明確地知道新的代碼應該放在哪里。
  隔離程度高，耦合程度低。一個模塊的代碼不容易影響到另一個模塊。
  易于團隊合作。各部分分工明確，團隊合作時易于統一代碼風格，可以快速接手別人的代碼。
• 缺點：
  一個模塊內的類數量增大，代碼量增大，在層與層之間需要花更多時間設計接口。
  模塊的初始化較為復雜，打開一個新的界面需要生成View、Presenter、Interactor，并且設置互相之間的依賴關系。而iOS中缺少這種設置復雜初始化的原生方式。