本文源自本人的學(xué)習(xí)記錄整理與理解，其中參考閱讀了部分優(yōu)秀的博客和書(shū)籍，盡量以通俗簡(jiǎn)單的語(yǔ)句轉(zhuǎn)述。引用到的地方如有遺漏或未能一一列舉原文出處還望見(jiàn)諒與指出，另文章內(nèi)容如有不妥之處還望指教，萬(wàn)分感謝 ！

何為架構(gòu) ？

架構(gòu)即Architecture, 是軟件開(kāi)發(fā)中的設(shè)計(jì)方案；
它可大可小，小到類(lèi)與類(lèi)之間的關(guān)系、模塊與模塊之間的關(guān)系；
大到客戶端與服務(wù)端之間的關(guān)系; 這些都可以認(rèn)為是一種架構(gòu)設(shè)計(jì)方案

經(jīng)常聽(tīng)到的架構(gòu)名詞

• MVC、MVP、MVVM、VIPER、CDD
• 三層架構(gòu)、四層架構(gòu)等等

Apple官方的MVC設(shè)計(jì)

M：數(shù)據(jù)模型 V: 視圖View C: 控制器

1. 控制器可以創(chuàng)建View，并顯示出來(lái)
2. View內(nèi)部的事件響應(yīng)可以交給控制器來(lái)處理，比如按鈕的點(diǎn)擊事件
3. 控制器可以通過(guò)發(fā)出網(wǎng)絡(luò)請(qǐng)求或從數(shù)據(jù)庫(kù)緩存中獲取數(shù)據(jù)，數(shù)據(jù)發(fā)生了改變控制器是可以知道的；會(huì)拿到View的屬性控件把數(shù)據(jù)賦值給它顯示
4. 控制器相當(dāng)于是數(shù)據(jù)和視圖之間的橋梁；數(shù)據(jù)模型和View是互相不知道的
   這種設(shè)計(jì)方案最經(jīng)典案例：UITableView 、UICollectionView

優(yōu)點(diǎn):
View和Model解耦，可重用
View不依賴數(shù)據(jù)模型，可以拿到任何地方使用；簡(jiǎn)稱(chēng)萬(wàn)能View
Model不依賴View，可以重復(fù)利用，可以獨(dú)立拿出來(lái)使用

缺點(diǎn)：
Controller 的代碼過(guò)于臃腫，維護(hù)成本高

Apple-MVC.png

MVC變種

1. 控制器可以創(chuàng)建View，并顯示出來(lái)
2. View內(nèi)部擁有模型，View內(nèi)部的事件響應(yīng)可以交給控制器來(lái)處理，比如按鈕的點(diǎn)擊事件
3. 控制器可以通過(guò)發(fā)出網(wǎng)絡(luò)請(qǐng)求或從數(shù)據(jù)庫(kù)緩存中獲取數(shù)據(jù)，接下來(lái)會(huì)把模型數(shù)據(jù)傳給View，有View自己負(fù)責(zé)顯示模型的數(shù)據(jù)

變種MVC.png

優(yōu)點(diǎn)：
對(duì)Controller進(jìn)行瘦身，將View內(nèi)部的細(xì)節(jié)封裝起來(lái)了，外界不知道View內(nèi)部的具體實(shí)現(xiàn)
缺點(diǎn)：
View依賴于Model，換Model可能會(huì)有點(diǎn)麻煩；別人要用就需要把數(shù)據(jù)變成這個(gè)Model傳遞

MVP

M：數(shù)據(jù)模型 V: View P: presenter 分擔(dān)控制器部分業(yè)務(wù)邏輯處理

1. 控制器內(nèi)部擁有presenter，負(fù)責(zé)初始化presenter
2. presenter專(zhuān)門(mén)來(lái)處理業(yè)務(wù)邏輯，可以聲明一個(gè)弱指針指向控制器；presenter內(nèi)部操作分三步：

• 創(chuàng)建View 給控制器顯示
• 加載模型 ：網(wǎng)絡(luò)請(qǐng)求或本地緩存
• 將模型數(shù)據(jù)給View顯示

MVP.png

優(yōu)點(diǎn)：
View和Model解耦 - 相互不知道，可重用
對(duì)Controller進(jìn)行瘦身，部分業(yè)務(wù)邏輯處理由presenter實(shí)現(xiàn); 同時(shí)Controller可以擁有多個(gè)presenter切換

缺點(diǎn)：
代碼量會(huì)比普通的MVC要大

MVVM

和MVP相似，最大不同在于MVVM是通過(guò)屬性監(jiān)聽(tīng)綁定的方式相互協(xié)作

M ：數(shù)據(jù)模型 V: View VM: 處理綁定和顯示

1. 控制器內(nèi)部擁有VM，負(fù)責(zé)初始化VM
2. VM專(zhuān)門(mén)來(lái)業(yè)務(wù)邏輯，可以聲明一個(gè)弱指針指向控制器；VM內(nèi)部操作分三步：

• 創(chuàng)建View給控制器顯示，View也聲明一個(gè)指針指向VM,即View擁有VM，并監(jiān)聽(tīng)VM屬性model的改變(facebook推出的FBKVOController)
  
  QQ20200421-123214.png
  
  當(dāng)然還有一個(gè)RAC框架可以做到，不過(guò)該框架內(nèi)容比較多；需要花一些時(shí)間
• 加載模型 ：網(wǎng)絡(luò)請(qǐng)求或本地緩存
• 設(shè)置數(shù)據(jù) ：把獲取到的數(shù)據(jù)賦值給自己的屬性模型

MVVM.png

優(yōu)點(diǎn)：
View和Model解耦 - 相互不知道，可重用
對(duì)Controller進(jìn)行瘦身，部分業(yè)務(wù)邏輯處理由VM實(shí)現(xiàn)，同時(shí)Controller可以擁有多個(gè)VM切換

缺點(diǎn)：
代碼量會(huì)比普通的MVC要大

分層架構(gòu)

比較成熟的有三層架構(gòu)和四層架構(gòu)

分層的基本思路：
一般來(lái)說(shuō)是把項(xiàng)目中的所有類(lèi)，不管是控制器、View、model、工具類(lèi)等對(duì)它們采用分層的設(shè)計(jì)，每層只需要專(zhuān)注自己的事情不需要關(guān)系其他層怎么做

三層架構(gòu)設(shè)計(jì)：應(yīng)用層、業(yè)務(wù)層、數(shù)據(jù)層

應(yīng)用層：界面相關(guān)的如：控制器、View控件， MVC、MVP、MVVM都是屬于該范疇
業(yè)務(wù)層：處理業(yè)務(wù)邏輯，比如商城應(yīng)用的購(gòu)物車(chē)業(yè)務(wù)、結(jié)算業(yè)務(wù)
數(shù)據(jù)層：網(wǎng)絡(luò)請(qǐng)求獲取數(shù)據(jù)、本地?cái)?shù)據(jù)庫(kù)

四層架構(gòu)設(shè)計(jì)：應(yīng)用層、業(yè)務(wù)層、網(wǎng)絡(luò)層、本地?cái)?shù)據(jù)層

應(yīng)用層：界面相關(guān)的如：控制器、View控件，MVC、MVP、MVVM都是屬于這個(gè)范疇
業(yè)務(wù)層：處理業(yè)務(wù)邏輯，比如商城應(yīng)用的購(gòu)物車(chē)業(yè)務(wù)、結(jié)算業(yè)務(wù)
網(wǎng)絡(luò)層：網(wǎng)絡(luò)請(qǐng)求獲取數(shù)據(jù)
本地?cái)?shù)據(jù)層：本地?cái)?shù)據(jù)庫(kù)

不管三層架構(gòu)還是四層架構(gòu)也好主要的還是依托項(xiàng)目的業(yè)務(wù)，做出合適的選擇，沒(méi)有最好只有只有最合適 ！

四層架構(gòu).png

組件化架構(gòu)

組件化要求：不能出現(xiàn)橫向依賴，不能出現(xiàn)反向依賴；

當(dāng)出現(xiàn)橫向依賴時(shí)考慮把組件下沉，以保證能夠?qū)崿F(xiàn)解耦合；即編程原則中的依賴倒置原則
反向依賴: 下層不能依賴上層，上層可以依賴下層；這是單向的依賴；即編程原則中的迪米特原則

隨著移動(dòng)互聯(lián)網(wǎng)的不斷發(fā)展，很多程序代碼量和業(yè)務(wù)越來(lái)越多，現(xiàn)有架構(gòu)已經(jīng)不適合公司業(yè)務(wù)的發(fā)展速度了，很多都面臨著重構(gòu)的問(wèn)題。
在公司項(xiàng)目開(kāi)發(fā)中，如果項(xiàng)目比較小，普通的單工程+MVC架構(gòu)就可以滿足大多數(shù)需求了。但是像淘寶、蘑菇街、微信這樣的大型項(xiàng)目，原有的單工程架構(gòu)就不足以滿足架構(gòu)需求了。

就拿淘寶來(lái)說(shuō)，淘寶在13年開(kāi)啟的“All in 無(wú)線”戰(zhàn)略中，就將阿里系大多數(shù)業(yè)務(wù)都加入到手機(jī)淘寶中，使客戶端出現(xiàn)了業(yè)務(wù)的爆發(fā)。在這種情況下，單工程架構(gòu)則已經(jīng)遠(yuǎn)遠(yuǎn)不能滿足現(xiàn)有業(yè)務(wù)需求了。所以在這種情況下，淘寶在13年開(kāi)啟了插件化架構(gòu)的重構(gòu)，后來(lái)在14年迎來(lái)了手機(jī)淘寶有史以來(lái)最大規(guī)模的重構(gòu)，將其徹底重構(gòu)為組件化架構(gòu)。

將每個(gè)模塊作為一個(gè)組件并且建立一個(gè)主項(xiàng)目，這個(gè)主項(xiàng)目負(fù)責(zé)集成所有組件；這樣的方式被稱(chēng)為組件化 ！
進(jìn)行組件化開(kāi)發(fā)后，可以把每個(gè)組件當(dāng)做一個(gè)獨(dú)立的app，每個(gè)組件甚至可以采取不同的架構(gòu)，例如分別使用MVVM、MVC、MVCS等架構(gòu)。

當(dāng)下組件化大多是基于CocoaPods實(shí)現(xiàn)組件化架構(gòu)，利用中間件來(lái)完成組件之間通信，在CocoaPods中可以通過(guò)podfile很好的配置各個(gè)組件，包括組件的增加和刪除，以及控制某個(gè)組件的版本。使用CocoaPods的原因，很大程度是為了解決大型項(xiàng)目中，代碼管理工具merge代碼導(dǎo)致的沖突。并且可以通過(guò)配置podfile文件，輕松配置項(xiàng)目。

注意：在組件化架構(gòu)是需要進(jìn)行分層的，這其中有分層架構(gòu)的思想在里面；層這個(gè)概念是用來(lái)區(qū)分組件的職能的，在項(xiàng)目越做越大的過(guò)程中分層的思想就變得非常重要；不然大家會(huì)把一個(gè)項(xiàng)目理解成一團(tuán)麻，沒(méi)有清晰的劃分對(duì)未來(lái)的擴(kuò)展和優(yōu)化非常不利；

架構(gòu)和設(shè)計(jì)模式的關(guān)系

設(shè)計(jì)模式即 Design Pattern,是一套被反復(fù)使用、代碼設(shè)計(jì)經(jīng)驗(yàn)的總結(jié)；使用設(shè)計(jì)模式的好處是：可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性；一般與編程語(yǔ)言無(wú)關(guān)，是一套比較成熟的編程思想

• 和架構(gòu)相比概念上會(huì)小一些，設(shè)計(jì)模式是策略，架構(gòu)模式是戰(zhàn)略

設(shè)計(jì)模式可以被分為三大類(lèi): 創(chuàng)建型模式、結(jié)構(gòu)型模式、行為型模式

創(chuàng)建型模式：對(duì)象實(shí)例化的模式，用于解耦隨想的實(shí)例化過(guò)程； 常見(jiàn)的有：單利模式、工廠模式等

結(jié)構(gòu)型模式：把類(lèi)或?qū)ο蠼Y(jié)合在一起形成一個(gè)更大的結(jié)構(gòu)；常見(jiàn)的有：代理模式、適配器模式、組合模式、裝飾模式等

行為型模式：類(lèi)或?qū)ο笾g如何交互，及劃分責(zé)任和算法；常見(jiàn)的有：觀察者模式、命令模式、責(zé)任鏈模式、訂閱者模式等

以上設(shè)計(jì)模式OC用到的不是很多，像java語(yǔ)言的設(shè)計(jì)模式就有23種；

推薦

數(shù)據(jù)結(jié)構(gòu)與算法 嚴(yán)蔚敏，《數(shù)據(jù)結(jié)構(gòu)》

image

大話數(shù)據(jù)結(jié)構(gòu)與算法 提取碼: f2ux

image

網(wǎng)絡(luò)

image

HTTP權(quán)威指南電子書(shū) 提取碼: bsji

《TCP/IP詳解卷1：協(xié)議》：買(mǎi)第一本就好

image

TCP/IP詳解卷1、2、3 電子書(shū) 提取碼: 35ei

架構(gòu)與設(shè)計(jì)模式

iOS 設(shè)計(jì)模式相關(guān)資料整理

圖說(shuō)設(shè)計(jì)模式