干净轻爽的View Controllers

翻译自原文

View Controllers通常是iOS工程中最大的文件了，它们经常包含了许多不必要的代码。一般来说，View Controllers 的代码是最难以服用的。下面我们来介绍一些减少View Controllers代码，使其可重用，以及将代码移至其它合适地方的技巧。

代码在Github上。

将Data Source和其它的协议分离开

一种最有效的减少View Controllers中代码的方式就是将 UITableViewDataSource 移至他自己的类里去。如果你不止一次需要用到这些东西，那么你就能看到这里面的模式并能够创建出一些可重用的类了。

例如，在我们的例子中，有一各类 PhotosViewController ，它有以下方法：

# pragma mark Pragma 

- (Photo*)photoAtIndexPath:(NSIndexPath*)indexPath {
    return photos[(NSUInteger)indexPath.row];
}

- (NSInteger)tableView:(UITableView*)tableView 
 numberOfRowsInSection:(NSInteger)section {
    return photos.count;
}

- (UITableViewCell*)tableView:(UITableView*)tableView 
        cellForRowAtIndexPath:(NSIndexPath*)indexPath {
    PhotoCell* cell = [tableView dequeueReusableCellWithIdentifier:PhotoCellIdentifier 
                                                      forIndexPath:indexPath];
    Photo* photo = [self photoAtIndexPath:indexPath];
    cell.label.text = photo.name;
    return cell;
}

许多这样的代码都得操作数组，有些代码其实是与photo相关联的。所以让我们尝试着将与数组相关联的代码移至它自己的类中去。我们使用 block 来配置单元格，但是使用 delegate 其实也可以，所以这完全取决于你的喜好。

@implementation ArrayDataSource

- (id)itemAtIndexPath:(NSIndexPath*)indexPath {
    return items[(NSUInteger)indexPath.row];
}

- (NSInteger)tableView:(UITableView*)tableView 
 numberOfRowsInSection:(NSInteger)section {
    return items.count;
}

- (UITableViewCell*)tableView:(UITableView*)tableView 
        cellForRowAtIndexPath:(NSIndexPath*)indexPath {
    id cell = [tableView dequeueReusableCellWithIdentifier:cellIdentifier
                                              forIndexPath:indexPath];
    id item = [self itemAtIndexPath:indexPath];
    configureCellBlock(cell,item);
    return cell;
}

@end

现在你的 view controller 中可以减少三个方法了，取而代之的是你现在可以创建一个这个object，然后将它设置为你的 table view 的数据源。

void (^configureCell)(PhotoCell*, Photo*) = ^(PhotoCell* cell, Photo* photo) {
   cell.label.text = photo.name;
};
photosArrayDataSource = [[ArrayDataSource alloc] initWithItems:photos
                                                cellIdentifier:PhotoCellIdentifier
                                            configureCellBlock:configureCell];
self.tableView.dataSource = photosArrayDataSource;

现在，你不用担心是否能将index path映射为数组位置的问题，每次当你想要显示数组的时候，你就可以重用这段代码。你也可以实现其它的方法例如 tableView:commitEditingStyle:forRowAtIndexPath: ，并在你得所有 table view controllers 中共享。

更加开心的事情是，现在我们可以单独测试这个类了，并且永远都不用重新编写它。这条原则也适用于其它你使用数组时的情况。

在我们今年所工作的一个应用中，我们大量依赖Core Data奇数。我们创建一个相同的类，但是我们并不是将其放置到一个array中，而是将其放置在了一个fetched result controller 中。它实现了所有的逻辑，更新，doing sectiong headers，以及删除。继而，你可以创建一个这样的类，然后给它一个请求，以及配置cell的一个block，剩下的事情都不用你操心了。

另外，这种方法也能扩展其它的protocols。另外一个候选者是 UICollectionViewDataSource 。这给了你极大的灵活性，在开发中，你决定使用 UICollectionView 而不是 UITableView ，你几乎不用修改任何View Controller中的代码。你可以让你的 data source 两种协议都支持。

将逻辑移至Model中

下面是一个例子，在view controller中尝试找到一个用户的一系列活跃特性。

- (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 类中的话，就更加整洁了。现在你的 View Controller.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];
}

确实，有些代码很难移至 model object 中，但是仍然可以清晰的将其与 model 代码关联起来。对于这些情况，可以使用 Store：

创建Store Class

在第一个版本种，我们需要写代码从文件中加载数据，现在它们在 view controller 中：

- (void)readArchive {
    NSBundle* bundle = [NSBundle bundleForClass:[self class]];
    NSURL *archiveURL = [bundle URLForResource:@"photodata"
                                 withExtension:@"bin"];
    NSAssert(archiveURL != nil, @"Unable to find archive in bundle.");
    NSData *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对象来做这些事情。通过将它分离开来，我们可以重用这些代码，并单独测试，然后使我们的view controller尽量保持短小。store对象可以关注数据加载，缓存，设置到数据库中等。store经常被称作一个 servie layer 或者 一个 repository (服务层或者仓库)。

将Web Service逻辑移至Model层

不要进行web service逻辑在你的view controller中。你应该将这些封装在一个单独的类中。你的view controller可以调用这些类中的方法，并以回调的方式来进行更新。你还可以将有关缓存和错误处理的代码也同样扔到这个类中去。

将View代码移至View层

复杂的view逻辑不应该在view controller中完成。不管你是用Interface builder，还是将你的代码都封装在了 UIView 的子类中。例如，如果你创建你自己的日期选择器，将这些代码放在 DatePickerView 中，比放在view controller中要有意义的多。再一次，这同样增加了复用性和简洁性。

如果你喜欢 Interface Builder，你也可以在 Interface Builder 中做这些事情，一些人假设这智能用在view controller上，但其实你也可以加载一个单独的nib文件来写自定义view。在我们的例子中，我们创建了一个PhotoCell.xib，它包含了photo cell所必须的布局。

正如你所看到的，我们在view上创建了一些属性，然后将它关联至子view。这种技术也适用于其它自定义view。

沟通

另外一些经常需要做的事情就是与其它的view controller，模型，试图进行沟通。当然这也正是一个view controller应该做的事情，但是我们仍然希望将代码写的越简洁越好。

有许多技术都可以用来在你的view controllers中和你的模型中进行沟通(KVO和查询结果的controller)，但是在view controller中沟通仍然不太容易写出干净的代码来。

我们经常有一些问题，一个view controller有一些状态，它与其它许多个 view controller进行沟通。经常，将这个状态携程一个单独的对象，然后在各个 view controller中进行传递。然后观察和修改这些状态即可。优势：它总在一个地方，我们不会陷入各种delegate回调中。这是一个复杂的主题，在未来我们会深入讨论。

总结

我们已经见识了一些减少view controller代码的技术。我们不会滥用这些技术，我们始终坚持一个原则：编写可维护的代码。通过了解这些模式，我们可以使我们的view controller保持干净整洁的风格～