你好,歡迎來到IOS教程網

 Ios教程網 >> IOS編程開發 >> IOS開發基礎 >> 一次簡單的 ViewModel 實踐:高效簡單地組織代碼

一次簡單的 ViewModel 實踐:高效簡單地組織代碼

編輯:IOS開發基礎

1.jpg

文/某鳥

前言

不知不覺,筆者也撸碼也已經一年多了。隨著撸碼的數量疾速上漲,如何高效,簡單的組織代碼,經常引起筆者的思考。作為一個方法論及其實踐者(這個定義是筆者自己胡謅的),始終希望能夠找到一些簡單、有效的方法來解決問題,由此,也開始了一段構建代碼的實踐體驗。

這次要分享的,是自己在長期實踐 MVVM 結構後,對 MVVM 框架的一些理解與自己的工作流程。其中或許還有一些地方拿捏欠妥,希望大家能一起相互交流。

前戲

ViewModel 這個概念是基於 MVVM 結構提出的,全稱應該叫做 Model-View-ViewModel,從結構上來說,應該是 Model-ViewModel-ViewController-View。簡單來說,就是在 MVC 結構的基礎上,將 ViewController 中數據相關的職能剝離出來,單獨形成一個結構層級。

關於 ViewModel 的詳細定義,可以參考這篇 MVVM介紹。

此外,在工作流中,筆者在一定程度上參考了 BDD 的代碼構建思路,雖然沒有真正意義上的按照行為構建測試代碼,但是其書寫過程與 BDD 確實有相似之處。關於 BDD,可以參考這篇 行為驅動測試。

為本篇文章所編寫的 Demo 已經傳至 Github:傳送門~

好吧,我們開始。

ViewModel 與 ViewController

基類

嗯,在這裡,需要用到 OOP 的經典模式 —— 繼承。

我們不打算把 ViewModel 的功能構建的太重,所以,它只需要一個指向擁有自己的 ViewController 指針,與一個賦值 ViewController 的工廠方法。 就像下面這段代碼:

//BCBaseViewModel.h
 
@interface BCBaseViewModel : NSObject
 
@property (nonatomic,weak,readonly) UIViewController *viewController;
 
+(BCBaseViewModel *)modelWithViewController:(UIViewController *)viewController;
 
@end

ViewModel 只需要一個 weak 類型的 viewController 指針指向自己的 viewController,而 viewModel 則由 viewController 使用 strong 指針持有,用於規避循環引用。

這樣,就足夠了。

委托者與代理者

為了讓 ViewModel 與 ViewController 的關系更加清晰,也為了能夠批量化的生產 ViewModel,接下來要定義的,就是 ViewModel 與 ViewController 的結構特征了。

在分析了 ViewModel 劃分層次的原因與主要承擔的功能之後,我們大致可以總結出這麼幾個特征:

  • ViewModel 與 ViewController 是一一對應的

  • ViewModel 實現的功能是從 ViewController 中剝離出來的

  • ViewModel 是 ViewController 的附屬對象

根據上面幾點特征,最容易想到的類間關系應該就是代理/委托關系了,把一眼就看到的關系說的復雜可能會招罵,但是對接下來的論述,上面多多少少會起到點決定性的作用。

比如,雖然確定了代理與委托,但究竟誰是代理者,誰是委托者呢?換句話說,誰是協議的制定方,而誰又是實現方呢?

筆者這裡給出兩個依據來確認。

  1. 協議方法是被動調用方法,也就是反向調用。基於此,協議的實現方,應該同時是事件的響應方,以事件驅動正向調用,再由此觸發反向調用。

  2. 協議的實現方實現的方法是通行,且抽象的。反推之,協議的制定方需要實現更難抽象或是更為具體的方法。 這個依據也可以從另外一個層面來理解,即協議的實現方的可替換性應該更強。

第一條依據相對毋庸置疑,畢竟 ViewController 是 View 的持有者與管理者,更是 View 與 ViewModel 相互影響的唯一渠道。讓 ViewModel 作為 View 事件的響應方來驅動 UIViewController,從結構上有些說不通。

第二條則是實踐得來的結論,在實際開發時,由外而內,視圖的修改頻度往往是大於數據的。因此,重構 ViewController 的概率也要大於重構 ViewModel 的概率。不過這種歸納性的結論無法一言蔽之,反而會建議諸位在實際的開發過程當中,應當針對這些開發訴求對結構做更靈活的調整和優化。

這次實踐,則會以 ViewModel 作為協議的制定方,來構建代碼。

讓協議輕一點

在 OC 中,有 @protocol 相關的一系列語法專門用於聲明與實現協議相關的所有功能。但是考慮到具體的 ViewModel 與 ViewController 之間的相互調用都各不相同,如果我們為每一組 ViewModel 與 ViewController 都聲明一份協議,並且交由彼此實現和調用,代碼量激增基本上是一種必然了。

為了讓整個協議結構輕一點,這裡並沒有采用 @protocol 相關語法來實現,而是利用如下代碼:

typedef NSUInteger BCViewControllerCallBackAction;
 
@interface UIViewController(ViewModel)
 
-(void)callBackAction:(BCViewControllerCallBackAction)action info:(id)info;
 
@end

這段代碼做了這麼幾件事:

  1. 利用分類,為 UIViewController 拓展了 ViewModel 相關的回調方法聲明。功能類似於父類聲明抽象接口,而交由子類去實現。

  2. 接口支持傳參,具體的類不再制定協議方法,而只需要協議參數。

  3. 將該分類聲明在 ViewModel 的基類中,即可保證對 ViewModel 可見的 UIViewController 都實現了協議方法,從而不需要再編寫 @protocol 段落。

在具體的 ViewModel 與 ViewController 子類中,只需要根據具體的需求設計回調參數,構建一個 對應的枚舉即可。

將整個協議結構輕質化,主要的原因是因為協議內容變動頻繁。使用枚舉而非 protocol,可以減小改動范圍,且代碼量較少,定制方便。

筆者曾經也嘗試過雙向抽象方法定義,即對 ViewModel 也做一些抽象方法,使雙方僅根據基類約定的協議工作。但實踐下來,ViewModel 的方法並不易於抽象,因為其公共方法往往直接體現了 ViewController 的數據需求。如果強行擬訂抽象方法,反而會在構建具體類時產生歸納困惑,由此產生的最壞結果就是放棄遵守協議,整個代碼反而會變的難以維護。

化需求為行為

在開發過程當中,最常見的開發流還是需求驅動型開發流。說白了,就是扔給你一張示意圖,有時運氣好點還有交互原型神馬的(運氣不好就是別人家的 App = =),然後就交由你任性的東一榔頭西一棒槌的寫寫畫畫。

這個時候,還是建議適當的規劃一下開發流程。主要是考慮這麼幾點:

  • 開發層級與順序;

  • 單位時間內只關心盡可能少的東西;

  • 易於構建和調試;

  • 合理簡省重復性工作。

其實說簡單點,就是讓整個工作流變的有規則和秩序,以確保開發有理有據且可控。另外,也能有效避免反錯的頻率和嚴重程度。

這裡,筆者不要臉的分享自己的簡易工作流。

整個過程並不復雜,其實就是先撸 ViewController 界面,遇到需要數據的地方,就在 ViewModel 中聲明一個方法,然後佯裝調用。撸的代碼大概是這個樣子的:

typedef NS_ENUM(BCViewControllerAction,BCTopViewCallBackAction){
    BCTopViewCallBackActionReloadTable = 1 < < 0,
    BCTopViewCallBackActionReloadResult = 1 << 1
};
 
@interface BCTopViewModel : BCBaseViewModel
 
- (NSString *)LEDString;
 
- (NSUInteger)operationCount;
 
- (NSString *)operationTextAtIndex:(NSUInteger)index;
 
- (void)undo;
 
- (void)clear;
 
@end
 
@interface BCTopViewController ()@property (nonatomic,strong) BCTopViewModel *model;
@property (nonatomic,weak) IBOutlet UITableView *operationTable;
@property (nonatomic,weak) IBOutlet UILabel *result;
@end
 
 
@implementation BCTopViewController
 
- (void)viewDidLoad{
    [super viewDidLoad];
    self.operationTable.tableFooterView = UIView.new;
    
}
 
#pragma mark - action
 
- (IBAction)undo:(UIButton *)sender{
    [self.model undo];
}
 
- (IBAction)clear:(UIButton *)sender{
    [self.model clear];
}
 
#pragma mark - call back
 
- (void)callBackAction:(BCViewControllerAction)action{
    if (action & BCTopViewCallBackActionReloadTable) {
        [self.operationTable reloadData];
    }
    if (action & BCTopViewCallBackActionReloadResult) {
        self.result.text = self.model.LEDString;
    }
}
 
#pragma mark - tableView datasource & delegate
 
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section{
    return self.model.operationCount;
}
 
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath{
    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:@"cell" forIndexPath:indexPath];
    cell.textLabel.text = [self.model operationTextAtIndex:indexPath.row];
    return cell;
}
 
@end

這樣開發利用了一個 Runtime trick,那就是 Nil 可以響應任何消息。

所以,雖然我們只聲明了方法,並沒有實現,上面的代碼也是隨時可以運行的。換言之,你可以隨時運行來調試界面,而不用擔心 ViewModel 的實現。

相對麻煩的是測試回調方法,筆者自己的建議是在編寫好回調方法之後,在 ViewController 中對應的 ViewModel正向調用之後直接調用自己的回調,如果遇到可能的網絡請求或者需要延時處理的回調,也可以考慮編寫一個基於 dispatch_after 的測試宏來測試回調。

一般來說,視圖界面層的開發總是所見即所得的,所以測試標准就是頁面需求本身。當肉眼可見的所有需求實現,我們的界面編寫也就告一段落了。當然了,此時的代碼依舊是脆弱的,因為我們只做了正向實現,還沒有做邊界用例測試,所以並不知道在非正常情況下,是否會出現什麼詭異的事情。

不過值得慶幸的是,我們已經成功的把 ViewController 中數據相關的部分成功的隔離了出去。在未來的測試中,發現的任何與數據相關的 BUG,我們都可以拍著胸脯說,它肯定和 ViewController 無關。

另外,一如我所說,需求本身就是頁面的測試標准。也就是說,當你實現了需求,你的視圖層就已經通過了測試。是的,我要開始套用 TDD 的思考方式了。我們已經拿著需求當了測試用例,並且一一 Pass。

而當我們開發完 ViewController 的同時,我們也已經為 ViewModel 聲明好了所有公共方法,並且在對應的位置做了調用。BDD 的要點在於 It...when...should 的行為斷言,在此時的環境下,It 就是 ViewModel,when 就是 ViewController 中的每次調用,而 should ,則對應著 ViewModel 所有數據接口所衍生出的變化。

換句話說,我們可能沒辦法從界面上看到所有的行為引發的變化,但是我們已經在 ViewModel 實現之前構建了一個可測試環境。如果時間充足的話,此時的第一件事應當是根據具體的調用環境,為每個公共方法編寫足夠強壯的測試代碼,來避免數據錯誤。

順便說幾句風月場上的虛話。在構建程序的時候,面向接口是優於面向實現的,因為在任何一個系統中,比起信息的產生,信息的傳遞更決定著系統本身是否強大。而編寫代碼的時候,先將抽象功能方法具體化,再將數據逐步抽象化,經歷一個類似梭型的過程,可以更完美的貼合“高內聚、低耦合”的目標。

Fat Model

如果單從 ViewModel 實踐上來說,以上的內容已然解釋的差不多了。不過鑒於筆者手賤撸了一整個 Demo,就額外解釋下其它幾個地方的設計了。

首先是關於胖 Model 的設計。關於胖瘦 Model 的概念筆者也是最近才從這篇 iOS 應用架構談 view層的組織和調用方案 上看到。在此之前,只是憑直覺和朋友討論過 Model 與 Model 之間也應該有所區分。

Model 的胖瘦是根據業務相關性來劃分的。所以,筆者有時會直接將胖 Model 稱之為業務層 Model 以區分瘦 Model。在示例代碼中,CalculatorBrain 應該算是一個相對標准的業務層 Model 了。

如果遇到單個 ViewModel(或者 MVC 中的 Controller)無法解決的需求時,就需要整體業務下沉,交給一個相對獨立的 Model 來解決問題。上層只持有該 Model 開放出來的接口,以此促成的業務層 Model,帶有明顯的業務痕跡,說白了,就是不容易復用。

不過,筆者自己的開發觀點是,弱業務相關的模塊復用性應該強,即功能應該盡量單元化。而強業務相關的模塊則應該有更好的重構性和替換性能,即盡可能的功能內聚。說簡單點,比如這個 Demo 不再是一個計算器,而需要變成一個計數器或者別的什麼,需要重構的就只有 CalculatorBrain 這個類。(當然,這只是基於假設,界面不變底層數據狂變的需求不敢想象…)

從另外一方面來看,在整個 MVVM 框架中,也可以將每個單獨的 ViewModel 視作一個管道。在整個業務鏈中做了雙向的抽象,使整個業務鏈各個部分的替換性都有所提升,筆者個人傾向於將其解釋為,通過設計中間層,均衡了上下層級的復雜度。

更輕量級的 ViewController

objccn.io 第一期的第一篇文章就是更輕量的 View Controllers。文章內曾提到,通過將各個 protocol 的實現挪到 ViewController 之外,來為 ViewController 瘦身。

筆者也曾是這個建議的實踐者之一,甚至一度認為這也是 ViewModel 的主要功能。不過隨著開發時間拉長,筆者不得不重新開始審視這個問題。

首先,這種方法會產生很多額外的接口。我們依舊用 UITableView 來舉例。 假設我們讓 ViewModel 實現了 UITableViewDelegate 與 UITableViewDataSource 協議。這個時候,如果 ViewController 的另一個控件想要根據 tableView 的滾動位置做出響應該怎麼辦呢?由於 ViewModel 才是 tableView 的 delegate,所以我們就需要為 ViewController 聲明額外的公共方法,供 ViewModel 在回調方法中調用。

而我們不難發現,基本所有視圖控件的 Delegate 協議都涉及到視圖本身的響應,只要涉及到同界面下不同控件元素的互動,就不可避免的需要 ViewController 的參與。

筆者也嘗試過將 UITableViewDelegate 實現在 ViewController 中,而把 UITableViewDataSource 托付給 ViewModel 的方式。蛋疼的事情發生在動態高度 Cell 的實現上,我們一方面在 ViewModel 內部給 tableView:cellForRowAtIndexPath 輸入數據,一方面卻又要為 tableView:heightForRowAtIndexPath: 開設接口提供相同的數據以供計算高度。

筆者最後總結了原因,是因為 View 層 與 ViewController 層本身是持有與被持有的依賴關系,所以任何類作為 ViewController 的類內實例來實現協議回調,實際上都是在跨層調用,所以,就注定要以額外的接口為代價,換言之,ViewController 的內聚性變差了。

而另外一方面的原因,則是關於測試。我們說 ViewController 難以測試的原因是因為在大部分情況下,它並沒有幾個像樣的公共方法,且私有方法中還有一大部分方法是傳參回調。如果我們將這些 protocol 實現在另一個類中,其實並不會提升它們的可測試性。更為行之有效的方式,應該是將 protocol 的實現與數據接口隔離開來,讓實現方通過接口來填充數據,而非自身。

在 Demo 中,TopViewModel 便為 cell 的內容填充開設了 operationCount 與 operationTextAtIndex: 這樣的數據接口。相信,為這樣的數據接口構造測試環境,要比為 tableView:cellForRowAtIndexPath 這種方法構造測試環境要簡單的多。從側面來看,這樣的接口反而更合適於測試覆蓋。

基於以上這兩點原因,在之後的開發中,筆者開始將越來越多的 protocol 又請回了 ViewController 中。並且,由於 ViewModel 的存在,筆者更傾向與將 ViewController 構建成為一個獨立實現且只負責實現界面布局、邏輯的類,讓一個類做更少的事,但做的更好。

後記

本文的相關 Demo,實現的功能並不復雜,甚至有些簡陋的不好見人。見責於筆者想象力不周,本著以實踐演示為主的心態,做個參考就好吧。

筆者自诩為方法論及其實踐者,比較認同“構建代碼的方法比代碼更有價值”這個觀點。寫出一兩句驚艷的代碼或許是運氣,掌握方法去構建代碼本身才是戰斗力吧。盡可能讓自己每一句代碼都有理有據,而不是隨心所欲,也覺得會比較負責,起碼寫起來有個交待。

以上的總結見識有限,很多地方或許會有疏漏之處,希望能與諸位看官一起交流,如果能指出其中疏漏甚至錯誤的觀點,那就不甚感激了。

另外,說點說出來就不嫌丟人的話。截至筆者寫完這篇博文,雖然對“設計模式”的相關概念有各種旁敲側擊的求證與查詢,但仍未系統學習過相關概念。說來慚愧,有時候自己花好大功夫才弄明白、想清楚的答案,突然發現某本書、某篇文章上早已幾句話講的明明白白,其實還挺挫敗的。次數多了,甚至會對未知的知識產生抗拒,用來安慰自己很牛逼,這也是特地聲明沒有系統學習的原因吧。

不過開發路漫漫,其實大家都知道,我們只不過是爬到巨人肩上的搬磚工人而已。回頭看看自己腳下的路,每一塊磚都足以讓自己自慚形穢,自欺欺人什麼的,也只不過是浮躁上頭,丟人現眼罷了。

所以筆者在寫本文的中途,已經購買了《設計模式:可復用面向對象軟件的基礎》一書,希望能系統的學習一些代碼的構建技巧吧(以後也好接著吹牛= =)。

後記的後記

筆者最近正在謀求一份新的工作,意向依舊是 iOS 開發,坐標仍舊是深圳。如果您有緣看到這篇文章,且希望我成為您並肩作戰的戰友,或是有個不錯的去處可以推薦的話,還希望您能與我聯系。在此先行謝過了~

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