iOS开发—使用VIPER构建iOS应用

建筑领域流行这样一句话，“咱们虽然在营造建筑，但建筑也会从新塑造咱们”。正如全部开发者最终领悟到的，这句话一样适用于构建软件。

 

编写代码中相当重要的是，须要使每一部分容易被识别，赋有一个特定而明显的目的，并与其余部分在逻辑关系中完美契合。这就是咱们所说的软件架构。好的架构不只让一个产品成功投入使用，还可让产品具备可维护性，并让人不断头脑清醒的对它进行维护！

 

在这篇文章中，咱们介绍了一种称之为  VIPER 的 iOS 应用架构的方式。VIPER 已经在不少大型的项目上成功实践，可是出于本文的目的咱们将经过一个待办事项清单 (to-do app) 来介绍 VIPER 。你能够在  GitHub 上关注这个项目。

 

什么是 VIPER？

测试永远不是构建 iOS 应用的主要部分。当咱们 ( Mutual Mobile) 着手改善咱们的测试实践时，咱们发现给 iOS 应用写测试代码很是困难。所以若是想要设法改变测试的现状，咱们首先须要一个更好的方式来架构应用，咱们称之为 VIPER。

 

VIPER 是一个建立 iOS 应用 简明构架的程序。VIPER 能够是视图 (View)，交互器 (Interactor)，展现器 (Presenter)，实体 (Entity) 以及路由 (Routing) 的首字母缩写。简明架构将一个应用程序的逻辑结构划分为不一样的责任层。这使得它更容易隔离依赖项 (如数据库)，也更容易测试各层间的边界处的交互：

 

大部分 iOS 应用利用 MVC 构建，使用 MVC 应用程序架构能够引导你将每个类看作模型，视图或控制器中的一个。但因为大部分应用程序的逻辑不会存在于模型或视图中，因此一般最终老是在控制器里实现。这就致使一个称为 重量级视图控制器的问题，在这里，视图控制器作了太多工做。为这些重量级视图控制器 瘦身并非 iOS 开发者寻求提升代码的质量所要面临的惟一挑战，但至少这是一个很好的开端。

 

VIPER 的不一样层提供了明确的程序逻辑以及导航控制代码来应对这个挑战，利用 VIPER ，你会注意到在咱们的待办事项示例清单中的视图控制器能够简洁高效，意义明确地控制视图。你也会发现视图控制器中代码和全部的其余类很容易理解，容易测试，理所固然也更易维护。

 

基于用例的应用设计

应用一般是一些用户用例的集合。用例也被称为验收标准，或行为集，它们用来描述应用的用途。清单能够根据时间，类型以及名字排序，这就是一个用例。用例是应用程序中用来负责业务逻辑的一层，应独立于用户界面的实现，同时要足够小，而且有良好的定义。决定如何将一个复杂的应用分解成较小的用例很是具备挑战性，而且须要长期实践，但这对于缩小你解决的问题时所要面临的范围及完成的每一个类的所要涉及的内容来讲，是颇有帮助的。

 

利用 VIPER 创建一个应用须要实施一组套件来知足全部的用例，应用逻辑是实现用例的主要组成部分，但却不是惟一。用例也会影响用户界面。另外一个重要的方面，是要考虑用例如何与其余应用程序的核心组件相互配合，例如网络和数据持久化。组件就比如用例的插件，VIPER 则用来描述这些组件的做用是什么，如何进行交互。

 

咱们其中一个用例，或者说待办事项清单中其中的一个需求是能够基于用户的选择来将待办事项分组。经过分离的逻辑将数据组织成一个用例，咱们可以在测试时使用户界面代码保持干净，用例更易组装，从而确保它如咱们预期的方式工做。

 

VIPER 的主要部分

VIPER 的主要部分是：

 

视图：根据展现器的要求显示界面，并将用户输入反馈给展现器。

交互器：包含由用例指定的业务逻辑。

展现器：包含为显示（从交互器接受的内容）作的准备工做的相关视图逻辑，并对用户输入进行反馈（从交互器获取新数据）。

实体：包含交互器要使用的基本模型对象。

路由：包含用来描述屏幕显示和显示顺序的导航逻辑。

 

这种分隔形式一样遵循 单一责任原则。交互器负责业务分析的部分，展现器表明交互设计师，而视图至关于视觉设计师。

 

如下则是不一样组件的相关图解，并展现了他们之间是如何关联的：

虽然在应用中 VIPER 的组件能够以任意顺序实现，咱们在这里选择按照咱们推荐的顺序来进行介绍。你会注意到这个顺序与构建整个应用的进程大体符合 -- 首先要讨论的是产品须要作什么，以及用户会如何与之交互。

 

交互器

交互器在应用中表明着一个独立的用例。它具备业务逻辑以操纵模型对象（实体）执行特定的任务。交互器中的工做应当独立与任何用户界面，一样的交互器能够同时运用于 iOS 应用或者 OS X 应用中。

 

因为交互器是一个 PONSO (Plain Old NSObject，普通的 NSObject)，它主要包含了逻辑，所以很容易使用 TDD 进行开发。

 

示例应用的主要用例是向用户展现全部的待办事项（好比任何截止于下周末的任务）。此类用例的业务逻辑主要是找出今天至下周末之间将要到期的待办事项，而后为它们分配一个相对的截止日期，好比今天，明天，本周之内，或者下周。

 

如下是来自 VTDListInteractor 的对应方法：

1. - (void)findUpcomingItems 
2. { 
3.     __weak typeof(self) welf = self; 
4.     NSDate* today = [self.clock today]; 
5.     NSDate* endOfNextWeek = [[NSCalendar currentCalendar] dateForEndOfFollowingWeekWithDate:today]; 
6.     [self.dataManager todoItemsBetweenStartDate:today endDate:endOfNextWeek completionBlock:^(NSArray* todoItems) { 
7.         [welf.output foundUpcomingItems:[welf upcomingItemsFromToDoItems:todoItems]]; 
8.     }]; 
9. } 

 

实体

实体是被交互器操做的模型对象，而且它们只被交互器所操做。交互器永远不会传输实体至表现层 (好比说展现器)。

 

实体也应该是 PONSOs。若是你使用 Core Data，最好是将托管对象保持在你的数据层以后，交互器不该与 NSManageObjects 协同工做。

 

这里是咱们的待办事项服务的实体：

1. @interface VTDTodoItem : NSObject 
2.  
3. @property (nonatomic, strong)   NSDate*     dueDate; 
4. @property (nonatomic, copy)     NSString*   name; 
5.  
6. + (instancetype)todoItemWithDueDate:(NSDate*)dueDate name:(NSString*)name; 
7.  
8. @end 

不要诧异于你的实体仅仅是数据结构，任何依赖于应用的逻辑都应该放到交互器中。

 

展现器

展现器是一个主要包含了驱动用户界面的逻辑的 PONSO，它老是知道什么时候呈现用户界面。基于其收集来自用户交互的输入功能，它能够在合适的时候更新用户界面并向交互器发送请求。

 

当用户点击 “+” 键新建待办事项时，addNewEntry 被调用。对于此项操做，展现器会要求 wireframe 显示用户界面以增长新项目：

1. - (void)addNewEntry 
2. { 
3.     [self.listWireframe presentAddInterface]; 
4. } 

展现器还会从交互器接收结果并将结果转换成可以在视图中有效显示的形式。

 

下面是如何从交互器接受待办事项的过程，其中包含了处理数据的过程并决定展示给用户哪些内容：

1. - (void)foundUpcomingItems:(NSArray*)upcomingItems 
2. { 
3.     if ([upcomingItems count] == 0) 
4.     { 
5.         [self.userInterface showNoContentMessage]; 
6.     } 
7.     else 
8.     { 
9.         [self updateUserInterfaceWithUpcomingItems:upcomingItems]; 
10.     } 
11. } 

实体永远不会由交互器传输给展现器，取而代之，那些无行为的简单数据结构会从交互器传输到展现器那里。这就防止了那些“真正的工做”在展现器那里进行，展现器只能负责准备那些在视图里显示的数据。

 

视图

视图通常是被动的，它一般等待展现器下发须要显示的内容，而不会向其索取数据。视图（例如登陆界面的登陆视图控件）所定义的方法应该容许展现器在高度抽象的层次与之交流。展现器经过内容进行表达，而不关心那些内容所显示的样子。展现器不知道 UILabel，UIButton 等的存在，它只知道其中包含的内容以及什么时候须要显示。内容如何被显示是由视图来进行控制的。

 

视图是一个抽象的接口 (Interface)，在 Objective-C 中使用协议被定义。一个 UIViewController 或者它的一个子类会实现视图协议。好比咱们的示例中 “添加” 界面会有如下接口：

1. @protocol VTDAddViewInterface  
2.  
3. - (void)setEntryName:(NSString *)name; 
4. - (void)setEntryDueDate:(NSDate *)date; 
5.  
6. @end 

视图和视图控制器一样会操纵用户界面和相关输入。由于一般来讲视图控制器是最容易处理这些输入和执行某些操做的地方，因此也就不难理解为何视图控制器老是这么大了。为了使视图控制器保持苗条，咱们须要使它们在用户进行相关操做的时候能够有途径来通知相关部分。视图控制器不该当根据这些行为进行相关决定，可是它应当将发生的事件传递到可以作决定的部分。

 

在咱们的例子中，Add View Controller 有一个事件处理的属性，它实现了以下接口：

1. @protocol VTDAddModuleInterface  
2.  
3. - (void)cancelAddAction; 
4. - (void)saveAddActionWithName:(NSString *)name dueDate:(NSDate *)dueDate 
5.  
6. @end 

当用户点击取消键的时候，视图控制器告知这个事件处理程序用户须要其取消此次添加的动做。这样一来，事件处理程序即可以处理关闭 add view controller 并告知列表视图进行更新。

 

视图和展现器之间边界处是一个使用  ReactiveCocoa 的好地方。在这个示例中，视图控制器能够返回一个表明按钮操做的信号。这将容许展现器在不打破职责分离的前提下轻松地对那些信号进行响应。

 

路由

屏幕间的路径会在交互设计师建立的线框 (wireframes) 里进行定义。在 VIPER 中，路由是由两个部分来负责的：展现器和线框。一个线框对象包括 UIWindow，UINavigationController，UIViewController 等部分，它负责建立视图/视图控制器并将其装配到窗口中。

 

因为展现器包含了响应用户输入的逻辑，所以它就拥有知晓什么时候导航至另外一个屏幕以及具体是哪个屏幕的能力。而同时，线框知道如何进行导航。在二者结合起来的状况下，展现器可使用线框来进行实现导航功能，它们二者一块儿描述了从一个屏幕至另外一个屏幕的路由过程。

 

线框同时也明显是一个处理导航转场动画的地方。来看看这个 add wireframe 中的例子吧：

1. @implementation VTDAddWireframe 
2.  
3. - (void)presentAddInterfaceFromViewController:(UIViewController *)viewController  
4. { 
5.     VTDAddViewController *addViewController = [self addViewController]; 
6.     addViewController.eventHandler = self.addPresenter; 
7.     addViewController.modalPresentationStyle = UIModalPresentationCustom; 
8.     addViewController.transitioningDelegate = self; 
9.  
10.     [viewController presentViewController:addViewController animated:YES completion:nil]; 
11.  
12.     self.presentedViewController = viewController; 
13. } 
14.  
15. #pragma mark - UIViewControllerTransitioningDelegate Methods 
16.  
17. - (id)animationControllerForDismissedController:(UIViewController *)dismissed  
18. { 
19.     return [[VTDAddDismissalTransition alloc] init]; 
20. } 
21.  
22. - (id)animationControllerForPresentedController:(UIViewController *)presented 
23.                                                                   presentingController:(UIViewController *)presenting 
24.                                                                       sourceController:(UIViewController *)source  
25. { 
26.     return [[VTDAddPresentationTransition alloc] init]; 
27. } 
28.  
29. @end 

应用使用了自定义的视图控制器转场来呈现 add view controller。由于线框部件负责实施这个转场，因此它成为了 add view controller 转场的委托，而且返回适当的转场动画。

 

利用 VIPER 组织应用组件

iOS 应用的构架须要考虑到 UIKit 和 Cocoa Touch 是创建应用的主要工具。架构须要和应用的全部组件都可以和平相处，但又须要为如何使用框架的某些部分以及它们应该在什么位置提供一些指导和建议。

 

iOS 应用程序的主力是 UIViewController，咱们不难想象找一个竞争者来取代 MVC 就能够避免大量使用视图控制器。可是视图控制器如今是这个平台的核心：它们处理设备方向的变化，回应用户的输入，和相似导航控制器之类的系统系统组件集成得很好，而如今在 iOS 7 中又能实现自定义屏幕之间的转换，功能实在是太强大了。

 

有了 VIPER，视图控制器便就能真正的作它原本应该作的事情了，那就是控制视图。 咱们的待办事项应拥有两个视图控制器，一个是列表视图，另外一个是新建待办。由于 add view controller 要作的全部事情就是控制视图，因此实现起来很是的简单基础：

1. @implementation VTDAddViewController 
2.  
3. - (void)viewDidAppear:(BOOL)animated  
4. { 
5.     [super viewDidAppear:animated]; 
6.  
7.     UITapGestureRecognizer *gestureRecognizer = [[UITapGestureRecognizer alloc] initWithTarget:self 
8.                                                                                         action:@selector(dismiss)]; 
9.     [self.transitioningBackgroundView addGestureRecognizer:gestureRecognizer]; 
10.     self.transitioningBackgroundView.userInteractionEnabled = YES; 
11. } 
12.  
13. - (void)dismiss  
14. { 
15.     [self.eventHandler cancelAddAction]; 
16. } 
17.  
18. - (void)setEntryName:(NSString *)name  
19. { 
20.     self.nameTextField.text = name; 
21. } 
22.  
23. - (void)setEntryDueDate:(NSDate *)date  
24. { 
25.     [self.datePicker setDate:date]; 
26. } 
27.  
28. - (IBAction)save:(id)sender  
29. { 
30.     [self.eventHandler saveAddActionWithName:self.nameTextField.text 
31.                                      dueDate:self.datePicker.date]; 
32. } 
33.  
34. - (IBAction)cancel:(id)sender  
35. { 
36.     [self.eventHandler cancelAddAction]; 
37. } 
38.  
39.  
40. #pragma mark - UITextFieldDelegate Methods 
41.  
42. - (BOOL)textFieldShouldReturn:(UITextField *)textField  
43. { 
44.     [textField resignFirstResponder]; 
45.  
46.     return YES; 
47. } 
48.  
49. @end 

应用在接入网络之后会变得更有用处，可是究竟该在何时联网呢？又由谁来负责启动网络链接呢？典型的状况下，由交互器来启动网络链接操做的项目，可是它不会直接处理网络代码。它会寻找一个像是 network manager 或者 API client 这样的依赖项。交互器可能聚合来自多个源的数据来提供所需的信息，从而完成一个用例。最终，就由展现器来采集交互器反馈的数据，而后组织并进行展现。

 

数据存储模块负责提供实体给交互器。由于交互器要完成业务逻辑，所以它须要从数据存储中获取实体并操纵它们，而后将更新后的实体再放回数据存储中。数据存储管理实体的持久化，而实体应该对数据库全然不知，正因如此，实体并不知道如何对本身进行持久化。

 

交互器一样不须要知道如何将实体持久化，有时交互器更但愿使用一个 data manager 来使其与数据存储的交互变得容易。Data manager 能够处理更多的针对存储的操做，好比建立获取请求，构建查询等等。这就使交互器可以将更多的注意力放在应用逻辑上，而没必要再了解实体是如何被汇集或持久化的。下面咱们举一个例子来讲明使用 data manager 有意义的，这个例子假设你在使用 Core Data。这是示例应用程序的 data manager 的接口：

1. @interface VTDListDataManager : NSObject 
2.  
3. @property (nonatomic, strong) VTDCoreDataStore *dataStore; 
4.  
5. - (void)todoItemsBetweenStartDate:(NSDate *)startDate endDate:(NSDate *)endDate completionBlock:(void (^)(NSArray *todoItems))completionBlock; 
6.  
7. @end 

当使用 TDD 来开发一个交互器时，是能够用一个测试用的模拟存储来代替生产环境的数据存储的。避免与远程服务器通信（网络服务）以及避免读取磁盘（数据库）能够加快你测试的速度并增强其可重复性。

 

将数据存储保持为一个界限清晰的特定层的缘由之一是，这可让你延迟选择一个特定的持久化技术。若是你的数据存储是一个独立的类，那你就可使用一个基础的持久化策略来开始你的应用，而后等到有意义的时候升级至 SQLite 或者 Core Data。而由于数据存储层的存在，你的应用代码库中就不须要改变任何东西。

 

在 iOS 的项目中使用 Core Data 常常比构架自己还容易引发更多争议。然而，利用 VIPER 来使用 Core Data 将给你带来使用 Core Data 的史无前例的良好体验。在持久化数据的工具层面上，Core Data 能够保持快速存取和低内存占用方面，简直是个神器。可是有个很恼人的地方，它会像触须同样把 NSManagedObjectContext 延伸至你全部的应用实现文件中，特别是那些它们不应待的地方。VIPER 可使 Core Data 待在正确的地方：数据存储层。

 

在待办事项示例中，应用仅有的两部分知道使用了 Core Data，其一是数据存储自己，它负责创建 Core Data 堆栈；另外一个是 data manager。Data manager 执行了获取请求，将数据存储返回的 NSManagedObject 对象转换为标准的 PONSO 模型对象，并传输回业务逻辑层。这样一来，应用程序核心将再也不依赖于 Core Data，附加获得的好处是，你也不再用担忧过时数据 (stale) 和没有良好组织的多线程 NSManagedObjects 来糟蹋你的工做成果了。

 

在经过请求访问 Core Data 存储时，data manager 中看起来是这样的：

1. @implementation VTDListDataManager 
2.  
3. - (void)todoItemsBetweenStartDate:(NSDate *)startDate endDate:(NSDate*)endDate completionBlock:(void (^)(NSArray *todoItems))completionBlock 
4. { 
5.     NSCalendar *calendar = [NSCalendar autoupdatingCurrentCalendar]; 
6.  
7.     NSPredicate *predicate = [NSPredicate predicateWithFormat:@"(date >= %@) AND (date <= %@)", [calendar dateForBeginningOfDay:startDate], [calendar dateForEndOfDay:endDate]]; 
8.     NSArray *sortDescriptors = @[]; 
9.  
10.     __weak typeof(self) welf = self; 
11.     [self.dataStore 
12.      fetchEntriesWithPredicate:predicate 
13.      sortDescriptors:sortDescriptors 
14.      completionBlock:^(NSArray* entries) { 
15.          if (completionBlock) 
16.          { 
17.              completionBlock([welf todoItemsFromDataStoreEntries:entries]); 
18.          } 
19.      }]; 
20. } 
21.  
22. - (NSArray*)todoItemsFromDataStoreEntries:(NSArray *)entries 
23. { 
24.     return [entries arrayFromObjectsCollectedWithBlock:^id(VTDManagedTodoItem *todo) { 
25.         return [VTDTodoItem todoItemWithDueDate:todo.date name:todo.name]; 
26.     }]; 
27. } 
28.  
29. @end 

与 Core Data 同样极富争议的恐怕就是 UI 故事板了。故事板具备不少有用的功能，若是彻底忽视它将会是一个错误。然而，调用故事版所能提供的全部功能来完成 VIPER 的全部目标仍然是很困难的。

 

咱们所能作出的妥协就是选择不使用 segues 。有时候使用 segues 是有效的，可是使用 segues 的危险性在于它们很难原封不动地保持屏幕之间的分离，以及 UI 和应用逻辑之间的分离。通常来讲，若是实现 prepareForSegue 方法是必须的话，咱们就尽可能不去使用 segues。

 

除此以外，故事板是一个实现用户界面布局有效方法，特别是在使用自动布局的时候。咱们选择在实现待办事项两个界面的实例中使用故事板，而且使用这样的代码来执行本身的导航操做。

1. static NSString *ListViewControllerIdentifier = @"VTDListViewController"; 
2.  
3. @implementation VTDListWireframe 
4.  
5. - (void)presentListInterfaceFromWindow:(UIWindow *)window  
6. { 
7.     VTDListViewController *listViewController = [self listViewControllerFromStoryboard]; 
8.     listViewController.eventHandler = self.listPresenter; 
9.     self.listPresenter.userInterface = listViewController; 
10.     self.listViewController = listViewController; 
11.  
12.     [self.rootWireframe showRootViewController:listViewController 
13.                                       inWindow:window]; 
14. } 
15.  
16. - (VTDListViewController *)listViewControllerFromStoryboard  
17. { 
18.     UIStoryboard *storyboard = [self mainStoryboard]; 
19.     VTDListViewController *viewController = [storyboard instantiateViewControllerWithIdentifier:ListViewControllerIdentifier]; 
20.     return viewController; 
21. } 
22.  
23. - (UIStoryboard *)mainStoryboard  
24. { 
25.     UIStoryboard *storyboard = [UIStoryboard storyboardWithName:@"Main" 
26.                                                          bundle:[NSBundle mainBundle]]; 
27.     return storyboard; 
28. } 
29.  
30. @end 

 

使用 VIPER 构建模块

通常在使用 VIPER 的时候，你会发现一个屏幕或一组屏幕倾向于聚在一块儿做为一个模块。模块能够以多种形式体现，但通常最好把它想成是一种特性。在播客应用中，一个模块多是音频播放器或订阅浏览器。然而在咱们的待办事项应用中，列表和添加事项的屏幕都将做为单独的模块被创建。

 

将你的应用做为一组模块来设计有不少好处，其中之一就是模块能够有很是明确和定义良好的接口，而且独立于其余的模块。这就使增长或者移除特性变得更加简单，也使在界面中向用户展现各类可变模块变得更加简单。

 

咱们但愿能将待办事项中各模块之间分隔更加明确，咱们为添加模块定义了两个协议。一个是模块接口，它定义了模块能够作什么；另外一个则是模块的代理，用来描述该模块作了什么。例如：

1. @protocol VTDAddModuleInterface  
2.  
3. - (void)cancelAddAction; 
4. - (void)saveAddActionWithName:(NSString *)name dueDate:(NSDate *)dueDate; 
5.  
6. @end 
7.  
8.  
9. @protocol VTDAddModuleDelegate  
10.  
11. - (void)addModuleDidCancelAddAction; 
12. - (void)addModuleDidSaveAddAction; 
13.  
14. @end 

由于模块必需要被展现，才能对用户产生价值，因此模块的展现器一般须要实现模型的接口。当另外一个模型想要展示当前模块时，它的展现器就须要实现模型的委托协议，这样它就能在展现时知道当前模块作了些什么。

 

一个模块可能包括实体，交互器和管理器的通用应用逻辑层，这些一般可用于多个屏幕。固然，这取决于这些屏幕之间的交互及它们的类似度。一个模块能够像在待办事项列表里面同样，简单的只表明一个屏幕。这样一来，应用逻辑层对于它的特定模块的行为来讲就很是特有了。

 

模块一样是组织代码的简便途径。将模块全部的编码都放在它本身的文件夹中并在 Xcode 中建一个 group，这会在你须要寻找和改变动加容易。当你在要寻找一个类时，它恰到好处地就在你所期待的地方，这种感受真是没法形容的棒。

 

利用 VIPER 创建模块的另外一个好处是它使得扩展到多平台时变得更加简单。独立在交互器层中的全部用例的应用逻辑容许你能够专一于为平板，电话或者 Mac 构建新的用户界面，同时能够重用你的应用层。

 

进一步来讲，iPad 应用的用户界面可以将部分 iPhone 应用的视图，视图控制器及展现器进行再利用。在这种状况下，iPad 屏幕将由 ‘super’ 展现器和线框来表明，这样能够利用 iPhone 使用过的展现器和线框来组成屏幕。创建进而维护一个跨多平台的应用是一个巨大的挑战，可是好的构架能够对整个模型和应用层的再利用有大幅度的提高，并使其实现起来更加容易。

 

利用 VIPER 进行测试

VIPER 的出现激发了一个关注点的分离，这使得采用 TDD 变得更加简便。交互器包含独立与任何 UI 的纯粹逻辑，这使测试驱动开发更加简单。同时展现器包含用来为显示准备数据的逻辑，而且它也独立于任何一个 UIKit 部件。对于这个逻辑的开发也很容易用测试来驱动。

 

咱们更倾向于先从交互器下手。用户界面里全部部分都服务于用例，而经过采用 TDD 来测试驱动交互器的 API 可让你对用户界面和用例之间的关系有一个更好的了解。

 

做为实例，咱们来看一下负责待办事项列表的交互器。寻找待办事项的策略是要找出全部的将在下周末前截止的项目，并将这些项目分别归类至截止于今天，明天，本周或者下周。

 

咱们编写的第一个测试是为了保证交互器可以找到全部的截止于下周末的待办事项：

1. - (void)testFindingUpcomingItemsRequestsAllToDoItemsFromTodayThroughEndOfNextWeek 
2. { 
3.     [[self.dataManager expect] todoItemsBetweenStartDate:self.today endDate:self.endOfNextWeek completionBlock:OCMOCK_ANY]; 
4.     [self.interactor findUpcomingItems]; 
5. } 

一旦知道了交互器找到了正确的待办事项后，咱们就须要编写几个小测试用来确认它确实将待办事项分配到了正确的相对日期组内（好比说今天，明天，等等）。

1. - (void)testFindingUpcomingItemsWithOneItemDueTodayReturnsOneUpcomingItemsForToday 
2. { 
3.     NSArray *todoItems = @[[VTDTodoItem todoItemWithDueDate:self.today name:@"Item 1"]]; 
4.     [self dataStoreWillReturnToDoItems:todoItems]; 
5.  
6.     NSArray *upcomingItems = @[[VTDUpcomingItem upcomingItemWithDateRelation:VTDNearTermDateRelationToday dueDate:self.today title:@"Item 1"]]; 
7.     [self expectUpcomingItems:upcomingItems]; 
8.  
9.     [self.interactor findUpcomingItems]; 
10. } 

既然咱们已经知道了交互器的 API 长什么样，接下来就是开发展现器。一旦展现器接收到了交互器传来的待办事项，咱们就须要测试看看咱们是否适当的将数据进行格式化而且在用户界面中正确的显示它。

1. - (void)testFoundZeroUpcomingItemsDisplaysNoContentMessage 
2. { 
3.     [[self.ui expect] showNoContentMessage]; 
4.  
5.     [self.presenter foundUpcomingItems:@[]]; 
6. } 
7.  
8. - (void)testFoundUpcomingItemForTodayDisplaysUpcomingDataWithNoDay 
9. { 
10.     VTDUpcomingDisplayData *displayData = [self displayDataWithSectionName:@"Today" 
11.                                                           sectionImageName:@"check" 
12.                                                                  itemTitle:@"Get a haircut" 
13.                                                                 itemDueDay:@""]; 
14.     [[self.ui expect] showUpcomingDisplayData:displayData]; 
15.  
16.     NSCalendar *calendar = [NSCalendar gregorianCalendar]; 
17.     NSDate *dueDate = [calendar dateWithYear:2014 month:5 day:29]; 
18.     VTDUpcomingItem *haircut = [VTDUpcomingItem upcomingItemWithDateRelation:VTDNearTermDateRelationToday dueDate:dueDate title:@"Get a haircut"]; 
19.  
20.     [self.presenter foundUpcomingItems:@[haircut]]; 
21. } 
22.  
23. - (void)testFoundUpcomingItemForTomorrowDisplaysUpcomingDataWithDay 
24. { 
25.     VTDUpcomingDisplayData *displayData = [self displayDataWithSectionName:@"Tomorrow" 
26.                                                           sectionImageName:@"alarm" 
27.                                                                  itemTitle:@"Buy groceries" 
28.                                                                 itemDueDay:@"Thursday"]; 
29.     [[self.ui expect] showUpcomingDisplayData:displayData]; 
30.  
31.     NSCalendar *calendar = [NSCalendar gregorianCalendar]; 
32.     NSDate *dueDate = [calendar dateWithYear:2014 month:5 day:29]; 
33.     VTDUpcomingItem *groceries = [VTDUpcomingItem upcomingItemWithDateRelation:VTDNearTermDateRelationTomorrow dueDate:dueDate title:@"Buy groceries"]; 
34.  
35.     [self.presenter foundUpcomingItems:@[groceries]]; 
36. } 

一样须要测试的是应用是否在用户想要新建待办事项时正确启动了相应操做：

1. - (void)testAddNewToDoItemActionPresentsAddToDoUI 
2. { 
3.     [[self.wireframe expect] presentAddInterface]; 
4.  
5.     [self.presenter addNewEntry]; 
6. } 

这时咱们能够开发视图功能了，而且在没有待办事项的时候咱们想要展现一个特殊的信息。

1. - (void)testShowingNoContentMessageShowsNoContentView 
2. { 
3.     [self.view showNoContentMessage]; 
4.  
5.     XCTAssertEqualObjects(self.view.view, self.view.noContentView, @"the no content view should be the view"); 
6. } 

有待办事项出现时，咱们要确保列表是显示出来的：

1. - (void)testShowingUpcomingItemsShowsTableView 
2. { 
3.     [self.view showUpcomingDisplayData:nil]; 
4.  
5.     XCTAssertEqualObjects(self.view.view, self.view.tableView, @"the table view should be the view"); 
6. } 

首先创建交互器是一种符合 TDD 的天然规律。若是你首先开发交互器，紧接着是展现器，你就能够首先创建一个位于这些层的套件测试，而且为实现这是实例奠基基础。因为你不须要为了测试它们而去与用户界面进行交互，因此这些类能够进行快速迭代。在你须要开发视图的时候，你会有一个能够工做并测试过的逻辑和表现层来与其进行链接。在快要完成对视图的开发时，你会发现第一次运行程序时全部部件都运行良好，由于你全部已经过的测试已经告诉你它能够工做。

 

结论

咱们但愿你喜欢这篇对 VIPER 的介绍。或许大家都很好奇接下来应该作什么，若是你但愿经过 VIPER 来对你下一个应用进行设计，该从哪里开始呢？

 

咱们不遗余力使这篇文章和咱们利用 VIPER 实现的应用实例足够明确而且进行了很好的定义。咱们的待办事项里列表程序至关直接简单，可是它准确地解释了如何利用 VIPER 来创建一个应用。在实际的项目中，你能够根据你本身的挑战和约束条件来决定要如何实践这个例子。根据以往的经验，咱们的每一个项目在使用 VIPER 时都或多或少地改变了一些策略，但它们无一例外的都从中得益，找到了正确的方向。

 

不少状况下因为某些缘由，你可能会想要偏离 VIPER 所指引的道路。可能你遇到了不少  'bunny' 对象，或者你的应用使用了故事板的 segues。不要紧的，在这些状况下，你只须要在作决定时稍微考虑下 VIPER 所表明的精神就好。VIPER 的核心在于它是创建在 单一责任原则上的架构。若是你碰到了些许麻烦，想一想这些原则再考虑如何前进。

 

你必定想知道在现有的应用中可否只用 VIPER 。在这种状况下，你能够考虑使用 VIPER 构建新的特性。咱们许多现有项目都使用了这个方法。你能够利用 VIPER 创建一个模块，这能帮助你发现许多创建在单一责任原则基础上形成难以运用架构的现有问题。

 

软件开发最伟大的事情之一就是每一个应用程序都是不一样的，而设计每一个应用的架构的方式也是不一样的。这就意味着每一个应用对于咱们来讲都是一个学习和尝试的机遇，若是你决定开始使用 VIPER，你会受益不浅。感谢你的阅读。

 

Swift 补充

苹果上周在 WWDC 介绍了一门称之为  Swift 的编程语言来做为 Cocoa 和 Cocoa Touch 开发的将来。如今发表关于 Swift 的完整意见还为时尚早，但众所周知编程语言对咱们如何设计和构建应用有着重大影响。咱们决定使用  Swift 重写咱们的待办事项清单，帮助咱们学习它对 VIPER 意味着什么。至今为止，收获颇丰。Swift 中的一些特性对于构建应用的体验有着显著的提高。

 

结构体

在 VIPER 中咱们使用小型，轻量级的 model 类来在好比从展现器到视图这样不一样的层间传递数据。这些 PONSOs 一般是只是简单地带有少许数据，而且一般这些类不会被继承。Swift 的结构体很是适合这个状况。下面的结构体的例子来自 VIPER Swift。这个结构体须要被判断是否相等，因此咱们重载了 == 操做符来比较这个类型的两个实例。

1. struct UpcomingDisplayItem : Equatable, Printable { 
2.     let title : String = "" 
3.     let dueDate : String = "" 
4.  
5.     var description : String { get { 
6.         return "\(title) -- \(dueDate)" 
7.     }} 
8.  
9.     init(title: String, dueDate: String) { 
10.         self.title = title 
11.         self.dueDate = dueDate 
12.     } 
13. } 
14.  
15. func == (leftSide: UpcomingDisplayItem, rightSide: UpcomingDisplayItem) -> Bool { 
16.     var hasEqualSections = false 
17.     hasEqualSections = rightSide.title == leftSide.title 
18.  
19.     if hasEqualSections == false { 
20.         return false 
21.     } 
22.  
23.     hasEqualSections = rightSide.dueDate == rightSide.dueDate 
24.  
25.     return hasEqualSections 
26. } 

 

类型安全

也许 Objective-C 和 Swift 的最大区别是它们在对于类型处理上的不一样。 Objective-C 是动态类型，而 Swift 故意在编译时作了严格的类型检查。对于一个相似 VIPER 的架构， 应用由不一样层构成，类型安全是提高程序员效率和设计架构有很是大的好处。编译器帮助你确保正确类型的容器和对象在层的边界传递。如上所示，这是一个使用结构体的好地方。若是一个结构体的被设计为存在于两层之间，那么因为类型安全，你能够保证它将永远没法脱离这些层之间。