1.MVC锌半、MVP蟆融、MVVM模式
MVC（Model司训、View除嘹、Controller）
MVC是比較直觀的架構(gòu)模式碗硬，最核心的就是通過Controller層來進行調(diào)控另伍，首先看一下官方提供的MVC示意圖：
image.png
- Model和View永遠不能相互通信商佛，只能通過Controller傳遞
- Controller可以直接與Model對話（讀寫調(diào)用Model）慎冤，Model通過NSNotification和KVO機制與Controller間接通信
Controller可以直接與View對話砌创，通過IBoutlet直接操作View虏缸，IBoutlet直接對應View控件（例如創(chuàng)建一個Button：需聲明一個IBOutlet UIButton *btn）,View通過action向Controller報告時間的發(fā)生（用戶點擊了按鈕）。Controller是View的直接數(shù)據(jù)源 - 優(yōu)點：對于混亂的項目組織方式嫩实，有了一個明確的組織方式刽辙。通過Controller來掌控全局，同時將View展示和Model的變化分開
- 缺點：愈發(fā)笨重的Controller甲献，隨著業(yè)務邏輯的增加宰缤，大量的代碼放進Controller，導致Controller越來越臃腫晃洒，堆積成千上萬行代碼慨灭，后期維護起來費時費力
MVP（Model、View锥累、Presenter）
MVP模式是MVC模式的一個演化版本缘挑，其中Model與MVC模式中Model層沒有太大區(qū)別，主要提供數(shù)據(jù)存儲功能桶略，一般都是用來封裝網(wǎng)絡(luò)獲取的json數(shù)據(jù)语淘；View與MVC中的View層有一些差別，MVP中的View層可以是viewController际歼、view等控件惶翻；Presenter層則是作為Model和View的中介，從Model層獲取數(shù)據(jù)之后傳給View鹅心。
image.png
從上圖可以看出吕粗，從MVC模式中增加了Persenter層，將UIViewController中復雜的業(yè)務邏輯旭愧、網(wǎng)絡(luò)請求等剝離出來颅筋。
- 優(yōu)點：模式和視圖完全分離，可以做到修改視圖而不影響模型输枯；更高效的使用模型议泵，View不依賴Model，可以說View能做到對業(yè)務邏輯完全分離
- 缺點：Persenter中除了處理業(yè)務邏輯以外桃熄，還要處理View-Model兩層的協(xié)調(diào)先口，也會導致Presenter層的臃腫
MVVM（Model、Controller/View、ViewModel）
- 在MVVM中碉京，view和ViewController聯(lián)系在一起厢汹，我們把它們視為一個組件，view和ViewController都不能直接飲用model谐宙，而是飲用視圖模型即ViewModel烫葬。
viewModel是一個用來放置用戶輸入驗證邏輯、視圖顯示邏輯卧惜、網(wǎng)絡(luò)請求等業(yè)務邏輯的地方厘灼，這樣的設(shè)計模式夹纫，會輕微增加代碼量咽瓷，但是會減少代碼的復雜性 - 優(yōu)點：View可以獨立于Model的變化和修改，一個ViewModel可以綁定到不同的View上舰讹，降低耦合茅姜，增加重用
- 缺點：過于簡單的項目不適用、大型的項目視圖狀態(tài)較多時構(gòu)建和維護成本太大
合理的運用架構(gòu)模式有利于項目月匣、團隊開發(fā)工作钻洒，大師到底選擇哪個設(shè)計模式，哪種設(shè)計模式更好锄开，就像本文開頭所說素标，不同的設(shè)計模式，只是讓不同的場景有了更多的選擇方案萍悴。根據(jù)項目場景和開發(fā)需求头遭，選擇最合適的解決方案。
2.關(guān)于RAC你有怎樣運用到解決不同API依賴關(guān)系
信號的依賴：使用場景是當信號A執(zhí)行完才會執(zhí)行信號B癣诱，和請求的依賴很類似计维，如果請求A請求完畢才執(zhí)行請求B，我們需要注意信號A必須要執(zhí)行發(fā)送完成信號撕予，否則信號B無法執(zhí)行
//這相當于網(wǎng)絡(luò)請求中的依賴鲫惶，必須先執(zhí)行完信號A才會執(zhí)行信號B
//經(jīng)常用作一個請求執(zhí)行完畢后，才會執(zhí)行另一個請求
//注意信號A必須要執(zhí)行發(fā)送完成信號实抡。否則信號B無法執(zhí)行
RACSignal *concatSignal = [self.signalA concat:self.signalB];
//這里我們是對這個拼接信號進行訂閱
[concatSignal subscribeNext:^(id x) {
NSLog(@"%@",x);
}];
3.@weakify和我們宏定義的WeakSelf有什么區(qū)別欠母？
@weakify可以多參數(shù)使用
4.微服務架構(gòu)攝像。
微服務架構(gòu)具有以下優(yōu)勢：
- 1.靈活和獨立的可擴展性
靈活擴展是微服務架構(gòu)的主要優(yōu)勢之一吆寨。與單片架構(gòu)不同赏淌，每個模塊都可以水平擴展并獨立于其他模塊。因此鸟废，微服務架構(gòu)非常適合大型項目猜敢。 - 2.獨立技術(shù)堆棧
在微服務架構(gòu)中，軟件工程師有機會使用各種工具和技術(shù)構(gòu)建APP。代碼可以用不同的編程語言編寫缩擂，這為APP開發(fā)過程增加了更多的靈活性鼠冕。 - 3.更好的故障隔離
如果一個服務失敗，它不會影響其他服務的功能胯盯。與其他體系結(jié)構(gòu)樣式相比懈费，在微服務中，系統(tǒng)繼續(xù)工作博脑，單片模式下的問題會影響整個APP憎乙。 - 4.易于部署和集成
死哦燃煤即使是小代碼更改的情況下，開發(fā)人員也必須再次部署APP叉趣，但在微服務架構(gòu)中泞边，部署變得更快更輕松。
由于所有服務都是圍繞單一業(yè)務流程構(gòu)建的疗杉，因此程序員不必修改和重新部署整個APP阵谚，只需要您需要的區(qū)域。因此烟具，改進產(chǎn)品也比較簡單梢什。
微服務可以通過全自動部署機制獨立部署。此外朝聋，通過使用開源持續(xù)集成工具嗡午，開發(fā)人員大大簡化了與第三方服務的集成。 - 5.容易理解
微服務體系結(jié)構(gòu)的另一個優(yōu)點是很容易理解系統(tǒng)是如何工作的以及它是如何開發(fā)的冀痕。當一個新的團隊成員來到這個項目并且必須快速鉆研它時荔睹，這特別有用。
那么在iOS中五河借鑒這種思想去構(gòu)建我們的App呢金度？是需要我們開發(fā)者自己去不斷探索的应媚。
