关于iOS开发:iOS开发-简化view-controller

导语

view controller 通常是一个我的项目中最宏大的文件，因为它外面常常蕴含了不属于它的代码，同时这也使它成为代码中最难以重用的局部。所以为 view controller 瘦身，让其中的代码复用性更强，把相干代码放到正确的中央显得尤其重要。

iOS 开发交换技术群：563513413，不论你是大牛还是小白都欢送入驻，分享 BAT, 阿里面试题、面试教训，探讨技术，大家一起交流学习成长！

将 Data Source 和其余协定拆散

为 view controller 瘦身最无效的办法就是把 UITableViewDataSource 中的代码移动到相干的类中，具体的办法能够参阅《iOS 利用开发 扼要 TableView》中的相干实现。

而更进一步，不只是 TableView，这个办法能够扩大到其余的协定上，比方 UICollectionViewDataSource。如果在开发中抉择应用 UICollectionView 代替 UITableView 时，这个办法能够让你简直不必批改 viewController 中的任何货色，甚至能够让 Data Source 同时反对两个协定，给予了极大的便利性。

将弱业务逻辑移到 Model 中

注：markdown 对代码块的语法是开始和完结行都要增加：“`, 其中 ` 为 windows 键盘左上角

首先是代码，以下的代码是帮忙用户查找优先事项的列表：

-(void)loadPriorities
{
    NSDate *now = [NSDate date];
    NSString *formatString = @”startDate <= %@ AND endDate >= %@”;
    NSPredicate *predicate = [NSPredicate predicateWithFormat:formatString, now, now];
    NSSet *priorities = [self.user.priorities filteredSetUsingPredicate:predicate];
    self.priorities = [priorities allObjects];
}

然而，如果把这些代码移动到 User 类中会让它变得更加清晰，这时 ViewController.m 中会是：

-(void)loadPriorities
{
    self.priorities = [self.user currentPriorities];
}

而 User + Extensions.m 中则是：

-(NSArray *)currentPriorities
{
    NSDate *now = [NSDate date];
    NSString *formatString = @”startDate <= %@ AND endDate >= %@”;
    NSPredicate *predicate = [NSPredicate predicateWithFormat:formatString, now, now];
    return [[self.priorities filteredSetUsingPredicate:predicate] allObjects];
}

将这些代码移动的根本原因是因为 ViewController.m 是大部分业务逻辑的载体，自身代码的复杂度曾经很高，所以这类跟业务关联不大的代码比方日期转换、图像裁剪、设定过滤器等的操作能够拆散到各自的类中实现，一方面为 viewController 减负，另一方面也能增进代码的复用。

对于这个题目的翻译我斟酌了比拟久的工夫，因为在原文中是 “Move Domain Logic into the Model”，意为“把 畛域逻辑 移到 Model 中”。对于“畛域逻辑 ”一词我进行过讲究，大抵意思为“ 稳固的、不会扭转的逻辑关系 ”，同时在原文中也是应用了 NSPredicate 作为例子援用，而我认为其例子中的代码也是与业务相干的，只不过关联性不大，而且不会轻易改变，所以应用了“ 弱业务逻辑 ”一词代替了“ 畛域逻辑”一词。

把数据处理的逻辑移到服务层

一些代码可能没方法很无效的挪动到 model 中，然而这些代码却和 model 中的代码有清晰的关联，对于这种问题，能够应用 Store。比方在上面的代码中，viewController 须要实现从一个文件中获取一些数据，并对其进行操作：

-(void)readArchive 
{
    NSBundle *bundle = [NSBundle bundleForClass:[self class]];
    NSURL *archiveURL = [bundle URLForResource:@”photodata” withExtension:@”bin”];
    NSDate *data = [NSData dataWithContentsOfURL:archiveURL options:0 error:NULL];
    NSKeyedUnarchiver *unarchiver = [[NSKeyedUnarchiver alloc] initForReadingWithData:data];
    _users = [unarchiver decodeObjectOfClass:[NSArray class] forKey:@”users”];
    _photos = [unarchiver decodeObjectOfClass:[NSArray class] forKey:@”photos”];
    [unarchiver finishDecoding];
}

事实上，view controller 不须要分明怎么实现这些货色，而应该将这些解决交给一个 store object 来实现。

通过对代码进行拆散，可能增进代码复用、对代码进行单元测试、放弃 view controller 整洁等。同时可能让 view controller 更多关注于业务自身的内容，把数据的读取、缓存、新建等操作交给服务层来解决。

把网络服务的逻辑移到 Model 层

这与下面提到的十分相似：不要把网络服务的逻辑放到 view controller 中，而应该把它们寄存到不同的类中。

对于 view controller，应该只是应用一个 completion block 来调用这些办法，而把网络申请、错误处理、缓存解决交给这些类来实现

把解决 view 的代码移到 view 层

无论是应用 Storyboard 还是纯代码编写 view，创立简单的 view 的工作不应该交给 view controller。

比方在须要创立一个日期选择器时，更好的办法是把这些代码放到 DatePickerView 中，而不是放到 ViewController 中，和之前一样，是为了复用和简便。至于如何应用 storyboard 对 view 进行设置这里不再赘述。

Communication（通信）

view controller 中最常产生的就是 通信，包含了和 view 层的通信、和 model 层的通信、和其余 view controller 的通信等。只管这是一个 view controller 必须做的事件，这里仍然有方法可能对代码进行缩减。

对于 view controller 和 view、view controller 和 model 之间的通信曾经存在大量的优良教训，比方应用 KVO 键值模式传值，或者应用 Core Data 中的 NSFetchedResultsController 等。然而，对于 view controller 之间的通信的相干办法却比拟少。

比方在我当初做的我的项目中，一个 view controller 须要依据使用者身份的不同（家长/老师）来对 view controller 的 state 进行不同的设置，而这个 view controller 又在不同的 state 下与不同的 view controller 通信，传递不同的值。在这种状况下 view controller 中的代码会变得相当臃肿和凌乱，所以正确的做法是把这些不同的 state 放到不同的 object 外面，再把它们传给 view controller，让它们依据这个 state 来进行设置和批改，使咱们不再须要被累赘的委托办法搞得非常凌乱。

而在另一种状况下，各个 view controller 之间的跳转逻辑十分复杂，存在着重大的横向依赖，在这种状况下就不合适应用一般的页面跳转模式，而应该应用“中介者模式”，创立一个 coordinator controller，让它来治理页面跳转的逻辑。

论断

事实上当初有各种各样的办法为 view controller 减负，它们无一例外都是向着一个指标后退：写出可保护的代码，只有把这些办法灵活运用，熟记于心，能力真正防止弄出轻便而又难以保护的 view controller。