你好,歡迎來到IOS教程網

 Ios教程網 >> IOS編程開發 >> IOS開發綜合 >> IOS架構總結

IOS架構總結

編輯:IOS開發綜合

1.MVC For Cocoa
Cocoa的MVC模式驅使人們寫出臃腫的視圖控制器,因為它們經常被混雜到View的生命周期中,因此很難說View和ViewController是分離的。盡管仍可以將業務邏輯和數據轉換到Model,但是大多數情況下當需要為View減負的時候我們卻無能為力了,View的最大的任務就是向Controller傳遞用戶動作事件。ViewController最終會承擔一切代理和數據源的職責,還負責一些分發和取消網絡請求以及一些其他的任務,因此它的名字的由來…你懂的。

這裡寫圖片描述
你可能會看見過很多次這樣的代碼:

var userCell = tableView.dequeueReusableCellWithIdentifier("identifier") as UserCell
userCell.configureWithUser(user)

這個cell,正是由View直接來調用Model,所以事實上MVC的原則已經違背了,但是這種情況是一直發生的甚至於人們不覺得這裡有哪些不對。如果嚴格遵守MVC的話,你會把對cell的設置放在 Controller 中,不向View傳遞一個Model對象,這樣就會大大增加Controller的體積。

“Cocoa 的MVC被寫成Massive View Controller 是不無道理的。”
直到進行單元測試的時候才會發現問題越來越明顯。因為你的ViewController和View是緊密耦合的,對它們進行測試就顯得很艱難–你得有足夠的創造性來模擬View和它們的生命周期,在以這樣的方式來寫View Controller的同時,業務邏輯的代碼也逐漸被分散到View的布局代碼中去。

“View和Controller的接口並不適合單元測試。”

2.MVP (MVP 實現了Cocoa的MVC的願景)

這裡寫圖片描述vcC01/bV4tCpysLH6aGjwP3I56OsztLDx7/J0tTX9rv509rV+7j2QXBwt7bOp8TatcTCt9PJt/7O8aOs08nL/MC0uLrU8Na00NDQrbX3yM7O8aOs0tS8sFZpZXe1vVZpZXe1xNW5yr6ho9XiuPaz9s/WsqLH0rHY0Ou0psDttcTOyszisru99r32ysfU2k1WUMSjyr3W0KOszazKsdKytObU2tPa0tTPwryv1tC3vbC41tChozwvcD4NCjxwPjxzdHJvbmc+My5NVlZNICZuZGFzaDsg1+7QwsfSysfX7s6wtPO1xE1WKFgpz7XB0LXE0rvUsTwvc3Ryb25nPjwvcD4NCjxwPk1WVk283Lm5ysdNVihYKc+1wdDX7tDCtcTSu9Sxo6zS8rTLyMPO0sPHz6PN+8v80tG+rb+8wse1vU1WKFgpz7XB0NbQ1q7HsNLRvq2z9s/WtcTOyszioaM8YnIgLz4NCrTTwO3C27Ljw+bAtL2yTVZWTb+0xvDAtLK7tO2jrM7Sw8fS0b6tt8ezo8rsz6RWaWV3us1Nb2RlbKOs0tS8sE1lZGl0b3KjrNTaTVZWTdbQy/zKx1ZpZXcgTW9kZWyhozwvcD4NCjxwPjxpbWcgYWx0PQ=="這裡寫圖片描述" src="/uploadfile/Collfiles/20160820/201608200933571248.png" title="\" />

它和MVP模式看起來非常像:

1.MVVM將ViewController視作View 2.在View和Model之間沒有緊密的聯系

 

此外,它還有像監管版本的MVP那樣的綁定功能,但這個綁定不是在View和Model之間而是在View和ViewModel之間。
那麼問題來了,在iOS中ViewModel實際上代表什麼?它基本上就是UIKit下的每個控件以及控件的狀態。ViewModel調用會改變Model同時會將Model的改變更新到自身並且因為我們綁定了View和ViewModel,第一步就是相應的更新狀態。

綁定

我在MVP部分已經提到這點了,但是該部分我們仍會繼續討論。
如果我們自己不想自己實現,那麼我們有兩種選擇:

基於KVO的綁定庫如 RZDataBinding 和 SwiftBond 完全的函數響應式編程,比如像ReactiveCocoa、RxSwift或者 PromiseKit
事實上,尤其是最近,你聽到MVVM就會想到ReactiveCoca,反之亦然。盡管通過簡單的綁定來使用MVVM是可實現的,但是ReactiveCocoa卻能更好的發揮MVVM的特點。
但是關於這個框架有一個不得不說的事實:強大的能力來自於巨大的責任。當你開始使用Reactive的時候有很大的可能就會把事情搞砸。換句話來說就是,如果發現了一些錯誤,調試出這個bug可能會花費大量的時間.

 

 

讓我們再來看看關於三個特性的評估:

    *任務均攤* -- 在例子中並不是很清晰,但是事實上,MVVM的View要比MVP中的View承擔的責任多。因為前者通過ViewModel的設置綁定來更新狀態,而後者只監聽Presenter的事件但並不會對自己有什麼更新。
    *可測試性* -- ViewModel不知道關於View的任何事情,這允許我們可以輕易的測試ViewModel。同時View也可以被測試,但是由於屬於UIKit的范疇,對他們的測試通常會被忽略。
    *易用性* -- 在我們例子中的代碼量和MVP的差不多,但是在實際開發中,我們必須把View中的事件指向Presenter並且手動的來更新View,如果使用綁定的話,MVVM代碼量將會小的多。

“MVVM很誘人,因為它集合了上述方法的優點,並且由於在View層的綁定,它並不需要其他附加的代碼來更新View,盡管這樣,可測試性依然很強。”

4.VIPER–把LEGO建築經驗遷移到iOS app的設計

VIPER是我們最後要介紹的,由於不是來自於MV(X)系列,它具備一定的趣味性。
迄今為止,劃分責任的粒度是很好的選擇。VIPER在責任劃分層面進行了迭代,VIPER分為五個層次:

VIPER
VIPER

交互器 – 包括關於數據和網絡請求的業務邏輯,例如創建一個實體(數據),或者從服務器中獲取一些數據。為了實現這些功能,需要使用服務、管理器,但是他們並不被認為是VIPER架構內的模塊,而是外部依賴。

    展示器 -- 包含UI層面的業務邏輯以及在交互器層面的方法調用。
    實體 -- 普通的數據對象,不屬於數據訪問層次,因為數據訪問屬於交互器的職責。
    路由器 -- 用來連接VIPER的各個模塊。

基本上,VIPER模塊可以是一個屏幕或者用戶使用應用的整個過程–想想認證過程,可以由一屏完成或者需要幾步才能完成,你的模塊期望是多大的,這取決於你。

    Model 邏輯通過把實體作為最小的數據結構轉換到交互器中。
    Controller/Presenter/ViewModel的UI展示方面的職責移到了Presenter中,但是並沒有數據轉換相關的操作。
    VIPER是第一個通過路由器實現明確的地址導航模式。

“找到一個適合的方法來實現路由對於iOS應用是一個挑戰,MV(X)系列避開了這個問題。”

  1. 上一頁:
  2. 下一頁:
蘋果刷機越獄教程| IOS教程問題解答| IOS技巧綜合| IOS7技巧| IOS8教程
Copyright © Ios教程網 All Rights Reserved