目錄
一、三層架構
二、視圖層架構
? 1、MVC
? 2、MVVM
一、架構分層
上一篇我們說到組件化開發是一個App最大一層的架構，那具體到了一個一個的業務組件里，比組件化開發小一點的架構就是三層架構。所謂三層架構就是指把項目中所有的類劃分到不同的層，目的是使項目邏輯更加清晰，提升開發和維護的效率，我們一般會把項目分為三層：數據層、業務層、視圖層。
- 數據層一般就是對網絡三方庫的封裝和對本地數據三方庫的封裝，調用數據層你就可以獲取到rawData；
- 業務層內部在調用數據層的API，業務層主要負責的是決定數據的來源是從網絡請求還是本地數據，然后等著數據層給它返回rawData，把rawData處理成視圖層能直接使用的Model、ModelArray等模型數據回調給視圖層；
- 視圖層內部在調用業務層的API，視圖層主要負責的是告訴業務層它想要什么數據（即想做什么業務）并傳遞一些必要的參數給業務層，然后等著業務層返回數據后直接拿著用就可以了。
注意：嚴格來講，三層架構并不真正就比組件化開發小，它們倆只是從不同的角度去做架構而已，往往是相互融合的，比如組件化開發里網絡庫就是三層架構里數據層的內容，UI庫就是三層架構里視圖層里的內容等，這里之所以說“三層架構是比組件化開發小一點的架構，主要是針對業務組件來說的”，當然甚至我們在不使用組件化開發時項目里依然可以使用三層架構。
二、視圖層架構
比三層架構再小一點的架構就是視圖層架構，我們常說的MVC、MVVM都是?視圖層的架構。
1、MVC
蘋果版MVC
MVC，即Model-View-Controller，它們的關系如下：
Model的職責：
- Model只負責封裝數據，不做任何其它操作。
View的職責：
- View負責顯示數據，那怎么顯示數據呢？View需要把供外界使用的子組件給暴露出去；
- View負責響應與業務有關的事件并交給Controller去處理，怎么交給Controller呢？通過代理、block、通知等；
- View負責響應與業務無關的事件，如某些事件會引發動畫效果等，這應該盡量在View內部完成。
Controller的職責：
- Controller負責持有View，創建View，并把View添加到窗口上顯示；
- Controller負責加載Model，加載完后就持有Model并顯示在相應的View上；
- Controller負責監聽View與業務有關的事件，并通過與Model的合作，來完成相應的業務；
- Controller負責監聽Model的變化，并通過與View的合作，來完成相應的業務。
蘋果版MVC的優勢就在于：
- Model和View之間沒有一點兒耦合，它們可以獨立使用，具有高度復用性。
缺點也很明顯：
- Controller的代碼過于臃腫，這主要體現在View的很多子組件暴露在外面，Model給View賦值的那個地方。
變種版MVC
變種版MVC是針對蘋果版MVC的缺點進行的，變種的核心就在于：View持有了Model，把數據顯示的邏輯放在了View內部來處理，而不再是通過View暴露子組件的方式來顯示數據了。
變種MVC的優勢就在于：
- 在一定程度上為Controller瘦了身；
- 將View內部的實現細節封裝起來了，外界不需要知道View內部的實現細節，只需要給它一個Model就可以了。
缺點也很明顯：
- View明顯耦合于Model，這個View無法再獨立使用，必須綁定某個特定的Model一起使用。（不過我覺得這是可以接受的，畢竟我們既然選擇了這種架構，就表明這種View專門就是用來綁定某個特定的Model顯示的，而如果我們需要讓一個View能顯示各種Model，那可能就會選擇蘋果版MVC，也就是說實際開發中可能蘋果版MVC和變種版MVC都有）
2、MVVM
但無論是蘋果版MVC還是變種版MVC，它們都有一個致命的缺陷，那就是隨著業務的增加，C會變得越來越臃腫，幾千行的代碼維護起來簡直就是噩夢，這主要是因為C干了太多的事，比如獲取數據、處理數據、存儲數據等。
那有沒有辦法解決這種情況呢？經過多年的實踐證明，MVVM是解決這種情況的有效辦法。
MVVM，即Model-View-ViewModel，它們的關系如下：
MVVM就是把MVC里Controller里獲取數據、處理數據、存儲數據的操作，還有其它一堆業務邏輯的代碼都放到了ViewModel里，從而達到為Controller瘦身的效果。
- 所謂獲取數據的操作是指調用業務層的API獲取數據；
- 所謂處理數據的操作是指ViewModel會針對Model一對一地創建外界真正使用到的屬性、這些屬性屬性通常搞成getter方法就可以了、對Model的原始屬性進行處理，以便外界能夠直接使用；
- 所謂存儲數據的操作是指ViewModel會把獲取并處理后的數據保存在自己內部供外界使用，而不是暴露給外界讓Controller去持有；
- 其它一堆業務邏輯的代碼。
注意一個ViewModel里不是非要把這幾件職責湊齊才配叫ViewModel，有其中的一部分也可以。
通常情況下ViewModel的創建主要有兩個觸發點：
1、為每個Model創建對應的ViewModel：只要接口返回的數據不是非常不符合主流的設計規范，那么如果接口返回的是字典，那這個字典絕對可以對應為Model，那么只要有一個Model，我們就得有與之對應的ViewModel來處理Model的數據————Model可能會有很多屬性，但View層只會展示部分屬性，而且有的屬性得處理一下才能供View層直接使用，所以這個ViewModel就會針對Model一對一地創建外界真正使用到的屬性、并對Model的原始屬性進行處理以便外界能夠直接使用、這些屬性屬性通常搞成getter方法就可以了（Swift、Dart直接搞getter方法就可以，OC得創建property然后再提供getter方法），此時這個ViewModel已經體現了ViewModel的模型性；這種情況下的ViewModel是適合添加獲取數據、存儲數據、處理其它業務邏輯的代碼的，盡管去添，這樣這個ViewModel就是具備了模型性和邏輯性的完整ViewModel；
2、ViewModel太小了不適合管更大的事、于是創建一個更大的ViewModel：但如果接口返回的是數組，一般都是數組內部的小字典才對應為一個Model，那當我們為這個Model創建對應的ViewModel之后，就意味著數組內的小字典才對應ViewModel內部的那個model屬性，而我們又必然需要把接收到的model數組轉換成viewModel數組，但是這個viewModel數組是不宜直接存儲在ViewModel內部的，因為這個viewModel數組里存儲的就是一個一個的ViewModel本身，而這個ViewModel的定位其實是對單個Model的一對一包裝、然后頂多是處理一下跟單個Model有關的業務邏輯，那這時如果允許它內部出現一個存儲了一堆它自己——即ViewModel——的數組，那就意味著這個ViewModel除了需要處理跟它一對一的那個model的業務邏輯，還需要處理一堆跟它并沒有多大關系的model的業務邏輯，這顯然違反了初衷，所以此時這個ViewModel最好不要多管閑事，只體現ViewModel的模型性就足夠了；此時我們就得再創建一個更大一層的ViewModel來處理業務邏輯了————獲取數據、存儲數據（這個大ViewModel一般會持有第一步的小ViewModel所構成的數組）、處理其它業務邏輯的代碼，其實這個觸發點也是很好找的，一般就是第1個觸發點創建出來的ViewModel只是一個Item對應的視圖模型，不適合去管更大的事，而這個更大一層的ViewModel則是統籌全部Item的視圖模型，而這個更大的ViewModel提現的更多的就是ViewModel的邏輯性。
綜上，如果接口返回的是字典，我們創建一個ViewModel就夠了，這個ViewModel既能體現模型性也能體現邏輯性（學生答題項目的接口設計是非常好的，基本就是這種情況，代碼邏輯非常清晰）；而如果接口返回的是數組，我們就得創建兩個有關聯的ViewModel了，小ViewModel專門處理數組里小字典的數據，著重體現模型性，大ViewModel專門處理獲取數據、存儲數據、處理其它業務邏輯的代碼，著重體現邏輯性（智能白板項目的接口設計有的不是那么好，可能會出現這種情況，因為需要分兩個ViewModel）；當然如果隨著業務的增加“一個ViewModel”或者“大ViewModel”里的代碼越來越復雜越來越龐大，那我們也可以考慮按業務模塊創建單獨業務模塊的ViewModel，然后讓“一個ViewModel”或者“大ViewModel”去持有這些單獨業務模塊的ViewModel來做整體的業務調度。（智能白板里演講模式模塊、跟隨模式模塊、分布式數據存儲模塊就開始采用這種方式了）。
其實做完上面的操作就已經是MVVM了，但是業界經常會在上面MVVM的基礎上再加個響應式編程，響應式編程可以為MVVM提供更加簡單優雅的雙向綁定，主要是指數據驅動UI，常用的響應式編程框架有RAC和RxSwift，可參看【RxSwift】RxSwift的理論知識、【RxSwift】RxSwift在MVVM方面的實際應用。
