自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

雜談: MVC/MVP/MVVM （二）

作者：佚名
移動開發(fā) iOS
本文為回答一位朋友關(guān)于MVC/MVP/MVVM架構(gòu)方面的疑問所寫， 旨在介紹iOS下MVC/MVP/MVVM三種架構(gòu)的設計思路以及各自的優(yōu)缺點。
  • MVP

MVC的缺點在于并沒有區(qū)分業(yè)務邏輯和業(yè)務展示, 這對單元測試很不友好. MVP針對以上缺點做了優(yōu)化, 它將業(yè)務邏輯和業(yè)務展示也做了一層隔離, 對應的就變成了MVCP. M和V功能不變, 原來的C現(xiàn)在只負責布局, 而所有的邏輯全都轉(zhuǎn)移到了P層.

對應關(guān)系如圖所示:   

 

 

業(yè)務場景沒有變化, 依然是展示三種數(shù)據(jù), 只是三個MVC替換成了三個MVP(圖中我只畫了Blog模塊), UserVC負責配置三個MVP(新建各自的VP, 通過VP建立C, C會負責建立VP之間的綁定關(guān)系), 并在合適的時機通知各自的P層(之前是通知C層)進行數(shù)據(jù)獲取, 各個P層在獲取到數(shù)據(jù)后進行相應處理, 處理完成后會通知綁定的View數(shù)據(jù)有所更新, V收到更新通知后從P獲取格式化好的數(shù)據(jù)進行頁面渲染, UserVC***將已經(jīng)渲染好的各個View進行布局即可. 另外, V層C層不再處理任何業(yè)務邏輯, 所有事件觸發(fā)全部調(diào)用P層的相應命令, 具體到代碼中如下:

  1. @interface BlogPresenter : NSObject 
  2.  
  3.   
  4.  
  5. + (instancetype)instanceWithUserId:(NSUInteger)userId; 
  6.  
  7.   
  8.  
  9. - (NSArray *)allDatas;//業(yè)務邏輯移到了P層 和業(yè)務相關(guān)的M也跟著到了P層 
  10.  
  11. - (void)refreshUserBlogsWithCompletionHandler:(NetworkTaskCompletionHander)completionHandler; 
  12.  
  13. - (void)loadMoreUserBlogsWithCompletionHandler:(NetworkTaskCompletionHander)completionHandler; 
  14.  
  15.   
  16.  
  17. @end 
  18.  
  19.  
  20. @interface BlogPresenter() 
  21.  
  22.   
  23.  
  24. @property (assign, nonatomic) NSUInteger userId; 
  25.  
  26. @property (strong, nonatomic) NSMutableArray *blogs; 
  27.  
  28. @property (strong, nonatomic) UserAPIManager *apiManager; 
  29.  
  30.   
  31.  
  32. @end 
  33.  
  34.   
  35.  
  36. @implementation BlogPresenter 
  37.  
  38.   
  39.  
  40. + (instancetype)instanceWithUserId:(NSUInteger)userId { 
  41.  
  42.     return [[BlogPresenter alloc] initWithUserId:userId]; 
  43.  
  44. } 
  45.  
  46.   
  47.  
  48. - (instancetype)initWithUserId:(NSUInteger)userId { 
  49.  
  50.     if (self = [super init]) { 
  51.  
  52.         self.userId = userId; 
  53.  
  54.         self.apiManager = [UserAPIManager new]; 
  55.  
  56.         //...略 
  57.  
  58.     } 
  59.  
  60. } 
  61.  
  62.   
  63.  
  64. #pragma mark - Interface 
  65.  
  66.   
  67.  
  68. - (NSArray *)allDatas { 
  69.  
  70.     return self.blogs; 
  71.  
  72. } 
  73.  
  74. //提供給外層調(diào)用的命令 
  75.  
  76. - (void)refreshUserBlogsWithCompletionHandler:(NetworkTaskCompletionHander)completionHandler { 
  77.  
  78.   
  79.  
  80.     [self.apiManager refreshUserBlogsWithUserId:self.userId completionHandler:^(NSError *error, id result) { 
  81.  
  82.         if (!error) { 
  83.  
  84.   
  85.  
  86.             [self.blogs removeAllObjects];//清空之前的數(shù)據(jù) 
  87.  
  88.             for (Blog *blog in result) { 
  89.  
  90.                 [self.blogs addObject:[BlogCellPresenter presenterWithBlog:blog]]; 
  91.  
  92.             } 
  93.  
  94.         } 
  95.  
  96.         completionHandler ? completionHandler(error, result) : nil; 
  97.  
  98.     }]; 
  99.  
  100. } 
  101.  
  102. //提供給外層調(diào)用的命令 
  103.  
  104. - (void)loadMoreUserBlogsWithCompletionHandler:(NetworkTaskCompletionHander)completionHandler { 
  105.  
  106.     [self.apiManager loadMoreUserBlogsWithUserId:self.userId completionHandler...] 
  107.  
  108. } 
  109.  
  110.   
  111.  
  112. @end 
  113.  
  114.  
  115. @interface BlogCellPresenter : NSObject 
  116.  
  117.   
  118.  
  119. + (instancetype)presenterWithBlog:(Blog *)blog; 
  120.  
  121.   
  122.  
  123. - (NSString *)authorText; 
  124.  
  125. - (NSString *)likeCountText; 
  126.  
  127.   
  128.  
  129. - (void)likeBlogWithCompletionHandler:(NetworkTaskCompletionHander)completionHandler; 
  130.  
  131. - (void)shareBlogWithCompletionHandler:(NetworkTaskCompletionHander)completionHandler; 
  132.  
  133. @end 
  134.  
  135.  
  136. @implementation BlogCellPresenter 
  137.  
  138.   
  139.  
  140. - (NSString *)likeCountText { 
  141.  
  142.     return [NSString stringWithFormat:@"贊 %ld", self.blog.likeCount]; 
  143.  
  144. } 
  145.  
  146.   
  147.  
  148. - (NSString *)authorText { 
  149.  
  150.     return [NSString stringWithFormat:@"作者姓名: %@", self.blog.authorName]; 
  151.  
  152. } 
  153.  
  154. //    ...略 
  155.  
  156. - (void)likeBlogWithCompletionHandler:(NetworkTaskCompletionHander)completionHandler { 
  157.  
  158.   
  159.  
  160.     [[UserAPIManager new] likeBlogWithBlogId:self.blogId userId:self.userId completionHandler:^(NSError *error, id result) { 
  161.  
  162.         if (error) { 
  163.  
  164.             //do fail 
  165.  
  166.         } else { 
  167.  
  168.             //do success 
  169.  
  170.             self.blog.likeCount += 1; 
  171.  
  172.         } 
  173.  
  174.         completionHandler ? completionHandler(error, result) : nil; 
  175.  
  176.     }]; 
  177.  
  178. } 
  179.  
  180. //    ...略 
  181.  
  182. @end  

BlogPresenter和BlogCellPresenter分別作為BlogViewController和BlogCell的P層, 其實就是一系列業(yè)務邏輯的集合. BlogPresenter負責獲取Blogs原始數(shù)據(jù)并通過這些原始數(shù)據(jù)構(gòu)造BlogCellPresenter, 而BlogCellPresenter提供格式化好的各種數(shù)據(jù)以供Cell渲染, 另外, 點贊和分享的業(yè)務現(xiàn)在也轉(zhuǎn)移到了這里.

業(yè)務邏輯被轉(zhuǎn)移到了P層, 此時的V層只需要做兩件事:

1.監(jiān)聽P層的數(shù)據(jù)更新通知, 刷新頁面展示.

2.在點擊事件觸發(fā)時, 調(diào)用P層的對應方法, 并對方法執(zhí)行結(jié)果進行展示.

  1. @interface BlogCell : UITableViewCell 
  2.  
  3. @property (strong, nonatomic) BlogCellPresenter *presenter; 
  4.  
  5. @end 
  6.  
  7.  
  8. @implementation BlogCell 
  9.  
  10.   
  11.  
  12. - (void)setPresenter:(BlogCellPresenter *)presenter { 
  13.  
  14.     _presenter = presenter; 
  15.  
  16.     //從Presenter獲取格式化好的數(shù)據(jù)進行展示 
  17.  
  18.     self.authorLabel.text = presenter.authorText; 
  19.  
  20.     self.likeCountLebel.text = presenter.likeCountText; 
  21.  
  22. //    ...略 
  23.  
  24. } 
  25.  
  26.   
  27.  
  28. #pragma mark - Action 
  29.  
  30.   
  31.  
  32. - (void)onClickLikeButton:(UIButton *)sender { 
  33.  
  34.     [self.presenter likeBlogWithCompletionHandler:^(NSError *error, id result) { 
  35.  
  36.         if (!error) {//頁面刷新 
  37.  
  38.             self.likeCountLebel.text = self.presenter.likeCountText; 
  39.  
  40.         } 
  41.  
  42. //        ...略 
  43.  
  44.     }]; 
  45.  
  46. } 
  47.  
  48.   
  49.  
  50. @end  

而C層做的事情就是布局和PV之間的綁定(這里可能不太明顯, 因為BlogVC里面的布局代碼是TableViewDataSource, PV綁定的話, 因為我偷懶用了Block做通知回調(diào), 所以也不太明顯, 如果是Protocol回調(diào)就很明顯了), 代碼如下:

  1. @interface BlogViewController : NSObject 
  2.  
  3.   
  4.  
  5. + (instancetype)instanceWithTableView:(UITableView *)tableView presenter:(BlogPresenter)presenter; 
  6.  
  7.   
  8.  
  9. - (void)setDidSelectRowHandler:(void (^)(Blog *))didSelectRowHandler; 
  10.  
  11. - (void)fetchDataWithCompletionHandler:(NetworkCompletionHandler)completionHandler; 
  12.  
  13. @end   

   

   

 

BlogViewController現(xiàn)在不再負責實際的數(shù)據(jù)獲取邏輯, 數(shù)據(jù)獲取直接調(diào)用Presenter的相應接口, 另外, 因為業(yè)務邏輯也轉(zhuǎn)移到了Presenter, 所以TableView的布局用的也是Presenter.allDatas. 至于Cell的展示, 我們替換了原來大量的Set方法, 讓Cell自己根據(jù)綁定的CellPresenter做展示. 畢竟現(xiàn)在邏輯都移到了P層, V層要做相應的交互也必須依賴對應的P層命令, 好在V和M仍然是隔離的, 只是和P耦合了, P層是可以隨意替換的, M顯然不行, 這是一種折中.

***是Scene, 它的變動不大, 只是替換配置MVC為配置MVP, 另外數(shù)據(jù)獲取也是走P層, 不走C層了(然而代碼里面并不是這樣的):

  1. - (void)configuration { 
  2.  
  3.   
  4.  
  5. //    ...其他設置 
  6.  
  7.     BlogPresenter *blogPresenter = [BlogPresenter instanceWithUserId:self.userId]; 
  8.  
  9.     self.blogViewController = [BlogViewController instanceWithTableView:self.blogTableView presenter:blogPresenter]; 
  10.  
  11.     [self.blogViewController setDidSelectRowHandler:^(Blog *blog) { 
  12.  
  13.         [self.navigationController pushViewController:[BlogDetailViewController instanceWithBlog:blog] animated:YES]; 
  14.  
  15.     }]; 
  16.  
  17. //    ...略 
  18.  
  19. } 
  20.  
  21.   
  22.  
  23. - (void)fetchData { 
  24.  
  25.   
  26.  
  27. //        ...略 
  28.  
  29.     [self.userInfoVC fetchData]; 
  30.  
  31.     [HUD show]; 
  32.  
  33.     [self.blogViewController fetchDataWithCompletionHandler:^(NSError *error, id result) { 
  34.  
  35.         [HUD hide]; 
  36.  
  37.     }]; 
  38.  
  39. //還是因為懶, 用了Block走C層轉(zhuǎn)發(fā)會少寫一些代碼, 如果是Protocol或者KVO方式就會用self.blogViewController.presenter了 
  40.  
  41. //不過沒有關(guān)系, 因為我們替換MVC為MVP是為了解決單元測試的問題, 現(xiàn)在的用法完全不影響單元測試, 只是和概念不符罷了. 
  42.  
  43. //        ...略 
  44.  
  45. }  

上面的例子中其實有一個問題, 即我們假定: 所有的事件都是由V層主動發(fā)起且一次性的. 這其實是不成立的, 舉個簡單的例子: 類似微信語音聊天之類的頁面, 點擊語音Cell開始播放, Cell展示播放動畫, 播放完成動畫停止, 然后播放下一條語音.

在這個播放場景中, 如果CellPresenter還是像上面一樣僅僅提供一個playWithCompletionHandler的接口是行不通的. 因為播放完成后回調(diào)肯定是在C層, C層在播放完成后會發(fā)現(xiàn)此時執(zhí)行播放命令的CellPresenter無法通知Cell停止動畫, 即事件的觸發(fā)不是一次性的. 另外, 在播放完成后, C層遍歷到下一個待播放CellPresenterX調(diào)用播放接口時, CellPresenterX因為并不知道它對應的Cell是誰, 當然也就無法通知Cell開始動畫, 即事件的發(fā)起者并不一定是V層.

針對這些非一次性或者其他層發(fā)起事件, 處理方法其實很簡單, 在CellPresenter加個Block屬性就行了, 因為是屬性, Block可以多次回調(diào), 另外Block還可以捕獲Cell, 所以也不擔心找不到對應的Cell. 大概這樣:

  1. @interface VoiceCellPresenter : NSObject 
  2.  
  3.   
  4.  
  5. @property (copy, nonatomic) void(^didUpdatePlayStateHandler)(NSUInteger); 
  6.  
  7.   
  8.  
  9. - (NSURL *)playURL; 
  10.  
  11. @end 
  12.  
  13.  
  14. @implementation VoiceCell 
  15.  
  16.   
  17.  
  18. - (void)setPresenter:(VoiceCellPresenter *)presenter { 
  19.  
  20.     _presenter = presenter; 
  21.  
  22.   
  23.  
  24.     if (!presenter.didUpdatePlayStateHandler) { 
  25.  
  26.         __weak typeof(self) weakSelf = self; 
  27.  
  28.         [presenter setDidUpdatePlayStateHandler:^(NSUInteger playState) { 
  29.  
  30.             switch (playState) { 
  31.  
  32.                 case Buffering: weakSelf.playButton... break; 
  33.  
  34.                 case Playing: weakSelf.playButton... break; 
  35.  
  36.                 case Paused: weakSelf.playButton... break; 
  37.  
  38.             } 
  39.  
  40.         }]; 
  41.  
  42.     } 
  43.  
  44. }  

播放的時候, VC只需要保持一下CellPresenter, 然后傳入相應的playState調(diào)用didUpdatePlayStateHandler就可以更新Cell的狀態(tài)了.

當然, 如果是Protocol的方式進行的VP綁定, 那么做這些事情就很平常了, 就不寫了.

MVP大概就是這個樣子了, 相對于MVC, 它其實只做了一件事情, 即分割業(yè)務展示和業(yè)務邏輯. 展示和邏輯分開后, 只要我們能保證V在收到P的數(shù)據(jù)更新通知后能正常刷新頁面, 那么整個業(yè)務就沒有問題. 因為V收到的通知其實都是來自于P層的數(shù)據(jù)獲取/更新操作, 所以我們只要保證P層的這些操作都是正常的就可以了. 即我們只用測試P層的邏輯, 不必關(guān)心V層的情況.

  • MVVM

MVP其實已經(jīng)是一個很好的架構(gòu), 幾乎解決了所有已知的問題, 那么為什么還會有MVVM呢?

仍然是舉例說明, 假設現(xiàn)在有一個Cell, 點擊Cell上面的關(guān)注按鈕可以是加關(guān)注, 也可以是取消關(guān)注, 在取消關(guān)注時, SceneA要求先彈窗詢問, 而SceneB則不做彈窗, 那么此時的取消關(guān)注操作就和業(yè)務場景強關(guān)聯(lián), 所以這個接口不可能是V層直接調(diào)用, 會上升到Scene層.具體到代碼中, 大概這個樣子:

  1. @interface UserCellPresenter : NSObject 
  2.  
  3.   
  4.  
  5. @property (copy, nonatomic) void(^followStateHander)(BOOL isFollowing); 
  6.  
  7. @property (assign, nonatomic) BOOL isFollowing; 
  8.  
  9.   
  10.  
  11. - (void)follow; 
  12.  
  13. @end 
  14.  
  15.  
  16. @implementation UserCellPresenter 
  17.  
  18.   
  19.  
  20. - (void)follow { 
  21.  
  22.     if (!self.isFollowing) {//未關(guān)注 去關(guān)注 
  23.  
  24. //        follow user 
  25.  
  26.     } else {//已關(guān)注 則取消關(guān)注 
  27.  
  28.   
  29.  
  30.         self.followStateHander ? self.followStateHander(YES) : nil;//先通知Cell顯示follow狀態(tài) 
  31.  
  32.         [[FollowAPIManager new] unfollowWithUserId:self.userId completionHandler:^(NSError *error, id result) { 
  33.  
  34.             if (error) { 
  35.  
  36.                 self.followStateHander ? self.followStateHander(NO) : nil;//follow失敗 狀態(tài)回退 
  37.  
  38.             } eles { 
  39.  
  40.                 self.isFollowing = YES; 
  41.  
  42.             } 
  43.  
  44.             //...略 
  45.  
  46.         }]; 
  47.  
  48.     } 
  49.  
  50. } 
  51.  
  52. @end 
  53.  
  54.  
  55. @implementation UserCell 
  56.  
  57.   
  58.  
  59. - (void)setPresenter:(UserCellPresenter *)presenter { 
  60.  
  61.     _presenter = presenter; 
  62.  
  63.   
  64.  
  65.     if (!_presenter.followStateHander) { 
  66.  
  67.         __weak typeof(self) weakSelf = self; 
  68.  
  69.         [_presenter setFollowStateHander:^(BOOL isFollowing) { 
  70.  
  71.             [weakSelf.followStateButton setImage:isFollowing ? : ...]; 
  72.  
  73.         }]; 
  74.  
  75.     } 
  76.  
  77. } 
  78.  
  79.   
  80.  
  81. - (void)onClickFollowButton:(UIButton *)button {//將關(guān)注按鈕點擊事件上傳 
  82.  
  83.     [self routeEvent:@"followEvent" userInfo:@{@"presenter" : self.presenter}]; 
  84.  
  85. } 
  86.  
  87.   
  88.  
  89. @end 
  90.  
  91.  
  92. @implementation FollowListViewController 
  93.  
  94.   
  95.  
  96. //攔截點擊事件 判斷后確認是否執(zhí)行事件 
  97.  
  98. - (void)routeEvent:(NSString *)eventName userInfo:(NSDictionary *)userInfo { 
  99.  
  100.   
  101.  
  102.     if ([eventName isEqualToString:@"followEvent"]) { 
  103.  
  104.         UserCellPresenter *presenter = userInfo[@"presenter"]; 
  105.  
  106.         [self showAlertWithTitle:@"提示" message:@"確認取消對他的關(guān)注嗎?" cancelHandler:nil confirmHandler: ^{ 
  107.  
  108.             [presenter follow]; 
  109.  
  110.         }]; 
  111.  
  112.     } 
  113.  
  114. } 
  115.  
  116.   
  117.  
  118. @end 
  119.  
  120.  
  121. @implementation UIResponder (Router) 
  122.  
  123.   
  124.  
  125. //沿著響應者鏈將事件上傳 事件最終被攔截處理 或者 無人處理直接丟棄 
  126.  
  127. - (void)routeEvent:(NSString *)eventName userInfo:(NSDictionary *)userInfo { 
  128.  
  129.     [self.nextResponder routeEvent:eventName userInfo:userInfo]; 
  130.  
  131. } 
  132.  
  133. @end  

Block方式看起來略顯繁瑣, 我們換到Protocol看看:

  1. @protocol UserCellPresenterCallBack 
  2.  
  3.   
  4.  
  5. - (void)userCellPresenterDidUpdateFollowState:(BOOL)isFollowing; 
  6.  
  7.   
  8.  
  9. @end 
  10.  
  11.   
  12.  
  13. @interface UserCellPresenter : NSObject 
  14.  
  15.   
  16.  
  17. @property (weak, nonatomic) id view; 
  18.  
  19. @property (assign, nonatomic) BOOL isFollowing; 
  20.  
  21.   
  22.  
  23. - (void)follow; 
  24.  
  25.   
  26.  
  27. @end 
  28.  
  29.  
  30. @implementation UserCellPresenter 
  31.  
  32.   
  33.  
  34. - (void)follow { 
  35.  
  36.     if (!self.isFollowing) {//未關(guān)注 去關(guān)注 
  37.  
  38. //        follow user 
  39.  
  40.     } else {//已關(guān)注 則取消關(guān)注 
  41.  
  42.   
  43.  
  44.         BOOL isResponse = [self.view respondsToSelector:@selector(userCellPresenterDidUpdateFollowState)]; 
  45.  
  46.         isResponse ? [self.view userCellPresenterDidUpdateFollowState:YES] : nil; 
  47.  
  48.         [[FollowAPIManager new] unfollowWithUserId:self.userId completionHandler:^(NSError *error, id result) { 
  49.  
  50.             if (error) { 
  51.  
  52.                 isResponse ? [self.view userCellPresenterDidUpdateFollowState:NO] : nil; 
  53.  
  54.             } eles { 
  55.  
  56.                 self.isFollowing = YES; 
  57.  
  58.             } 
  59.  
  60.             //...略 
  61.  
  62.         }]; 
  63.  
  64.     } 
  65.  
  66. } 
  67.  
  68. @end 
  69.  
  70.  
  71. @implementation UserCell 
  72.  
  73.   
  74.  
  75. - (void)setPresenter:(UserCellPresenter *)presenter { 
  76.  
  77.   
  78.  
  79.     _presenter = presenter; 
  80.  
  81.     _presenter.view = self; 
  82.  
  83. } 
  84.  
  85.   
  86.  
  87. #pragma mark - UserCellPresenterCallBack 
  88.  
  89.   
  90.  
  91. - (void)userCellPresenterDidUpdateFollowState:(BOOL)isFollowing { 
  92.  
  93.     [self.followStateButton setImage:isFollowing ? : ...]; 
  94.  
  95. }  

除去Route和VC中Alert之類的代碼, 可以發(fā)現(xiàn)無論是Block方式還是Protocol方式因為需要對頁面展示和業(yè)務邏輯進行隔離, 代碼上饒了一小圈, 無形中增添了不少的代碼量, 這里僅僅只是一個事件就這樣, 如果是多個呢? 那寫起來真是蠻傷的…

仔細看一下上面的代碼就會發(fā)現(xiàn), 如果我們繼續(xù)添加事件, 那么大部分的代碼都是在做一件事情: P層將數(shù)據(jù)更新通知到V層. Block方式會在P層添加很多屬性, 在V層添加很多設置Block邏輯. 而Protocol方式雖然P層只添加了一個屬性, 但是Protocol里面的方法卻會一直增加, 對應的V層也就需要增加的方法實現(xiàn).

問題既然找到了, 那就試著去解決一下吧, OC中能夠?qū)崿F(xiàn)兩個對象間的低耦合通信, 除了Block和Protocol, 一般都會想到KVO. 我們看看KVO在上面的例子有何表現(xiàn):

  1. @interface UserCellViewModel : NSObject 
  2.  
  3.   
  4.  
  5. @property (assign, nonatomic) BOOL isFollowing; 
  6.  
  7.   
  8.  
  9. - (void)follow; 
  10.  
  11. @end 
  12.  
  13.  
  14. @implementation UserCellViewModel 
  15.  
  16.   
  17.  
  18. - (void)follow { 
  19.  
  20.     if (!self.isFollowing) {//未關(guān)注 去關(guān)注 
  21.  
  22. //        follow user 
  23.  
  24.     } else {//已關(guān)注 則取消關(guān)注 
  25.  
  26.   
  27.  
  28.         self.isFollowing = YES;//先通知Cell顯示follow狀態(tài) 
  29.  
  30.         [[FollowAPIManager new] unfollowWithUserId:self.userId completionHandler:^(NSError *error, id result) { 
  31.  
  32.             if (error) { self.isFollowing = NO; }//follow失敗 狀態(tài)回退 
  33.  
  34.             //...略 
  35.  
  36.         }]; 
  37.  
  38.     } 
  39.  
  40. } 
  41.  
  42. @end 
  43.  
  44.  
  45. @implementation UserCell 
  46.  
  47. - (void)awakeFromNib { 
  48.  
  49.     @weakify(self); 
  50.  
  51.     [RACObserve(self, viewModel.isFollowing) subscribeNext:^(NSNumber *isFollowing) { 
  52.  
  53.         @strongify(self); 
  54.  
  55.         [self.followStateButton setImage:[isFollowing boolValue] ? : ...]; 
  56.  
  57.     }; 
  58.  
  59. }  

代碼大概少了一半左右, 另外, 邏輯讀起來也清晰多了, Cell觀察綁定的ViewModel的isFollowing狀態(tài), 并在狀態(tài)改變時, 更新自己的展示.

三種數(shù)據(jù)通知方式簡單一比對, 相信哪種方式對程序員更加友好, 大家都心里有數(shù), 就不做贅述了.

現(xiàn)在大概一提到MVVM就會想到RAC, 但這兩者其實并沒有什么聯(lián)系, 對于MVVM而言RAC只是提供了優(yōu)雅安全的數(shù)據(jù)綁定方式, 如果不想學RAC, 自己搞個KVOHelper之類的東西也是可以的. 另外 ,RAC的魅力其實在于函數(shù)式響應式編程, 我們不應該僅僅將它局限于MVVM的應用, 日常的開發(fā)中也應該多使用使用的.

關(guān)于MVVM, 我想說的就是這么多了, 因為MVVM其實只是MVP的綁定進化體, 除去數(shù)據(jù)綁定方式, 其他的和MVP如出一轍, 只是可能呈現(xiàn)方式是Command/Signal而不是CompletionHandler之類的, 故不做贅述.

***做個簡單的總結(jié)吧:

1.MVC作為老牌架構(gòu), 優(yōu)點在于將業(yè)務場景按展示數(shù)據(jù)類型劃分出多個模塊, 每個模塊中的C層負責業(yè)務邏輯和業(yè)務展示, 而M和V應該是互相隔離的以做重用, 另外每個模塊處理得當也可以作為重用單元. 拆分在于解耦, 順便做了減負, 隔離在于重用, 提升開發(fā)效率. 缺點是沒有區(qū)分業(yè)務邏輯和業(yè)務展示, 對單元測試不友好.

2.MVP作為MVC的進階版, 提出區(qū)分業(yè)務邏輯和業(yè)務展示, 將所有的業(yè)務邏輯轉(zhuǎn)移到P層, V層接受P層的數(shù)據(jù)更新通知進行頁面展示. 優(yōu)點在于良好的分層帶來了友好的單元測試, 缺點在于分層會讓代碼邏輯優(yōu)點繞, 同時也帶來了大量的代碼工作, 對程序員不夠友好.

3.MVVM作為集大成者, 通過數(shù)據(jù)綁定做數(shù)據(jù)更新, 減少了大量的代碼工作, 同時優(yōu)化了代碼邏輯, 只是學習成本有點高, 對新手不夠友好.

4.MVP和MVVM因為分層所以會建立MVC兩倍以上的文件類, 需要良好的代碼管理方式.

5.在MVP和MVVM中, V和P或者VM之間理論上是多對多的關(guān)系, 不同的布局在相同的邏輯下只需要替換V層, 而相同的布局不同的邏輯只需要替換P或者VM層. 但實際開發(fā)中P或者VM往往因為耦合了V層的展示邏輯退化成了一對一關(guān)系(比如SceneA中需要顯示”xxx+Name”, VM就將Name格式化為”xxx + Name”. 某一天SceneB也用到這個模塊, 所有的點擊事件和頁面展示都一樣, 只是Name展示為”yyy + Name”, 此時的VM因為耦合SceneA的展示邏輯, 就顯得比較尷尬), 針對此類情況, 通常有兩種辦法, 一種是在VM層加狀態(tài)進而判斷輸出狀態(tài), 一種是在VM層外再加一層FormatHelper. 前者可能因為狀態(tài)過多顯得代碼難看, 后者雖然比較優(yōu)雅且拓展性高, 但是過多的分層在數(shù)據(jù)還原時就略顯笨拙, 大家應該按需選擇.

這里隨便瞎扯一句, 有些文章上來就說MVVM是為了解決C層臃腫, MVC難以測試的問題, 其實并不是這樣的. 按照架構(gòu)演進順序來看, C層臃腫大部分是沒有拆分好MVC模塊, 好好拆分就行了, 用不著MVVM. 而MVC難以測試也可以用MVP來解決, 只是MVP也并非***, 在VP之間的數(shù)據(jù)交互太繁瑣, 所以才引出了MVVM. 當MVVM這個完全體出現(xiàn)以后, 我們從結(jié)果看起源, 發(fā)現(xiàn)它做了好多事情, 其實并不是, 它的前輩們付出的努力也并不少!

  • 架構(gòu)那么多, 日常開發(fā)中到底該如何選擇?

不管是MVC, MVP, MVVM還是MVXXX, 最終的目的在于服務于人, 我們注重架構(gòu), 注重分層都是為了開發(fā)效率, 說到底還是為了開心. 所以, 在實際開發(fā)中不應該拘泥于某一種架構(gòu), 根據(jù)實際項目出發(fā), 一般普通的MVC就能應對大部分的開發(fā)需求, 至于MVP和MVVM, 可以嘗試, 但不要強制.

總之, 希望大家能做到: 設計時, 心中有數(shù). 擼碼時, 開心就好. 

責任編輯：龐桂玉 來源： iOS大全
MVCMVPMVVM
相關(guān)推薦

2017-03-31 20:45:41

MVCMVPMVVM

2018-03-21 16:19:40

MVCMVPMVVM

2014-03-17 11:05:00

ScriptCode Blocks

2019-09-11 08:52:24

MVCMVPMVVM

2019-10-30 14:58:45

MVCAndroid表現(xiàn)層

2023-04-11 07:50:27

軟件架構(gòu)設計

2018-10-29 11:41:22

架構(gòu)MVCAndroid

2023-10-20 13:21:55

軟件設計模式架構(gòu)

2017-05-12 16:50:14

GUI應用程序

2015-12-04 09:33:15

程序員前端演進史

2009-04-30 15:56:50

三層架構(gòu)MVCMVP

2009-07-24 13:54:39

MVVM模式

2012-05-28 10:34:50

MVVM 數(shù)據(jù)綁定

2017-02-24 14:05:14

AndroidMVCMVP

2009-12-21 09:22:51

SilverlightMVVM模式

2018-07-10 10:00:15

Android架構(gòu)MVC

2010-01-27 08:44:56

ASP.NET MVC

2016-03-30 09:34:27

2015-09-29 10:07:58

中文編碼

2012-11-05 14:57:50

MVP
點贊
收藏

51CTO技術(shù)棧公眾號