一、View层架构是影响业务方迭代周期的因素之一

一期PRD里的任务量和任务复杂度都会影响迭代周期能达到什么样的程度。抛开这些外在的不谈，从内在可能导致迭代周期达不到合理的速度的原因来看，其中有一个原因很有可能就是View层架构没有做好，让业务工程师完成一个不算复杂的需求时，需要处理太多额外的事情。

一般来说，一个不够好的View层架构，主要原因有以下五种：

• 代码混乱不规范
• 过多继承导致的复杂依赖关系
• 模块化程度不够高，组件粒度不够细
• 横向依赖
• 架构设计失去传承

二、View层架构是最贴近业务的底层架构

View层架构虽然也算底层，但还没那么底层，它跟业务的对接面最广，影响业务层代码的程度也最深。在所有的底层都牵一发的时候，在View架构上牵一发导致业务层动全身的面积最大。

所以View架构在所有架构中一旦定型，可修改的空间就最小，我们在一开始考虑View相关架构时，不光要实现功能，还要考虑更多规范上的东西。制定规范的目的一方面是防止业务工程师的代码腐蚀View架构，另一方面也是为了能够有所传承。按照规范来，总还是不那么容易出差池的。

还有就是，架构师一开始考虑的东西也会有很多，不可能在第一版就把它们全部实现，对于一个尚未发版的App来说，第一版架构往往是最小完整功能集，那么在第二版第三版的发展过程中，架构的迭代任务就很有可能不只是你一个人的事情了，相信你一个人也不见得能搞定全部。所以你要跟你的合作者们有所约定。另外，第一版出去之后，业务工程师在使用过程中也会产生很多修改意见，哪些意见是合理的，哪些意见是不合理的，也要通过事先约定的规范来进行筛选，最终决定如何采纳。

三、View代码结构的规定

架构师不是写SDK出来交付业务方使用就没事儿了的，每家公司一定都有一套代码规范，架构师的职责也包括定义代码规范。按照道理来讲，定代码规范应该是属于通识，放在这里讲的原因只是因为我这边需要为View添加一个规范。

制定代码规范严格来讲不属于View层架构的事情，但它对View层架构未来的影响会比较大，也是属于架构师在设计View层架构时需要考虑的事情。制定View层规范的重要性在于：

• 提高业务方View层的可读性可维护性
• 防止业务代码对架构产生腐蚀
• 确保传承
• 保持架构发展的方向不轻易被不合理的意见所左右

首先苹果有一套《Coding Guidelines》,当我们定代码结构或规范的时候，首先一定要符合这个规范。

然后，相信大家各自公司里面也都有一套自己的规范，具体怎么个规范法其实也是根据各位架构师的经验而定，我这边只是建议各位在各自规范的基础上再加上下面这一点。

规范.png

不要在viewDidLoad里面初始化你的view然后再add，这样代码就很难看。在viewDidload里面只做addSubview的事情，然后在viewWillAppear里面做布局的事情，最后在viewDidAppear里面做Notification的监听之类的事情。至于属性的初始化，则交给getter去做。比如说：

<pre>

pragma mark - life cycle

• (void)viewDidLoad
  {
  [super viewDidLoad];

  self.view.backgroundColor = [UIColor whiteColor];
  [self.view addSubview:self.firstTableView];
  [self.view addSubview:self.secondTableView];
  [self.view addSubview:self.firstFilterLabel];
  [self.view addSubview:self.secondFilterLabel];
  [self.view addSubview:self.cleanButton];
  [self.view addSubview:self.originImageView];
  [self.view addSubview:self.processedImageView];
  [self.view addSubview:self.activityIndicator];
  [self.view addSubview:self.takeImageButton];
  }

• (void)viewWillAppear:(BOOL)animated
  {
  [super viewWillAppear:animated];

  CGFloat width = (self.view.width - 30) / 2.0f;

  self.originImageView.size = CGSizeMake(width, width);
  [self.originImageView topInContainer:70 shouldResize:NO];
  [self.originImageView leftInContainer:10 shouldResize:NO];

  self.processedImageView.size = CGSizeMake(width, width);
  [self.processedImageView right:10 FromView:self.originImageView];
  [self.processedImageView topEqualToView:self.originImageView];

  CGFloat labelWidth = self.view.width - 100;
  self.firstFilterLabel.size = CGSizeMake(labelWidth, 20);
  [self.firstFilterLabel leftInContainer:10 shouldResize:NO];
  [self.firstFilterLabel top:10 FromView:self.originImageView];

  ... ...
  }
  </pre>

其次：

• getter和setter全部都放在最后

• 每一个delegate都把对应的protocol名字带上，delegate方法不要到处乱写，写到一块区域里面去

• event response专门开一个代码区域

• 关于private methods，正常情况下ViewController里面不应该写
  不是delegate方法的，不是event response方法的，不是life cycle方法的，就是private method了。对的，正常情况下ViewController里面一般是不会存在private methods的，这个private methods一般是用于日期换算、图片裁剪啥的这种小功能。这种小功能要么把它写成一个category，要么把他做成一个模块，哪怕这个模块只有一个函数也行。
  ViewController基本上是大部分业务的载体，本身代码已经相当复杂，所以跟业务关联不大的东西能不放在ViewController里面就不要放。另外一点，这个private method的功能这时候只是你用得到，但是将来说不定别的地方也会用到，一开始就独立出来，有利于将来的代码复用。

四、关于View的布局

直接使用CGRectMake的话可读性很差，光看那几个数字，也无法知道view和view之间的位置关系。用Autolayout可读性稍微好点儿，但生成Constraint的长度实在太长，代码观感不太好。Autolayout这边可以考虑使用Masonry，代码的可读性就能好很多。

五、何时使用storyboard，何时使用nib，何时使用代码写View

我更加提倡用code去画view而不是storyboard。

六、是否有必要让业务方统一派生ViewController

我觉得没有必要，为什么没有必要？

1.使用派生比不使用派生更容易增加业务方的使用成本
2.不使用派生手段一样也能达到统一设置的目的

为什么使用了派生，业务方的使用成本会提升？

• 集成成本
  对于业务层存在的所有父类来说，它们是很容易跟项目中的其他代码纠缠不清的，这使得业务方开发时遇到一个两难问题：要么把所有依赖全部搞定，然后基于App环境（下开发Demo，要么就是自己Demo写好之后，按照环境要求改代码。这里的两难问题都会带来成本，都会影响业务方的迭代进度。

• 上手接受成本
  新来的业务工程师有的时候不见得都记得每一个ViewController都必须要派生自TMViewController而不是直接的UIViewController。新来的工程师他不能直接按照苹果原生的做法去做事情，他需要额外学习，比如说：所有的ViewController都必须继承自TMViewController。

• 架构的维护难度

那么如果不使用派生，我们应该使用什么手段？
我的建议是使用AOP。

在架构师实现具体的方案之前，必须要想清楚几个问题，然后才能决定采用哪种方案。是哪几个问题？

1. 方案的效果，和最终要达到的目的是什么？
2. 在自己的知识体系里面，是否具备实现这个方案的能力？
3. 在业界已有的开源组件里面，是否有可以直接拿来用的轮子？

我们先看第一个问题：方案的效果，和最终要达到的目的是什么？
方案的效果应该是：

1. 业务方可以不用通过继承的方法，然后框架能够做到对ViewController的统一配置。
2. 业务方即使脱离框架环境，不需要修改任何代码也能够跑完代码。业务方的ViewController一旦丢入框架环境，不需要修改任何代码，框架就能够起到它应该起的作用。

其实就是要实现不通过业务代码上对框架的主动迎合，使得业务能够被框架感知这样的功能。细化下来就是两个问题，框架要能够拦截到ViewController的生命周期，另一个问题就是，拦截的定义时机。

对于方法拦截，很容易想到Method Swizzling，那么我们可以写一个实例，在App启动的时候添加针对UIViewController的方法拦截，这是一种做法。还有另一种做法就是，使用NSObject的load函数，在应用启动时自动监听。使用后者的好处在于，这个模块只要被项目包含，就能够发挥作用，不需要在项目里面添加任何代码。

然后另外一个要考虑的事情就是，原有的TMViewController（所谓的父类）也是会提供额外方法方便子类使用的，Method Swizzling只支持针对现有方法的操作，拓展方法的话，嗯，当然是用Category啦。

七、MVC、MVVM等一大堆思想

其实这些都是相对通用的思想，万变不离其宗的还是在开篇里面我提到的那三个角色：数据管理者，数据加工者，数据展示者。这些五花八门的思想，不外乎就是制订了一个规范，规定了这三个角色应当如何进行数据交换。但同时这些也是争议最多的话题，所以我在这里来把几个主流思想做一个梳理，当你在做View层架构时，能够有个比较好的参考。

• MVC

M应该做的事：
1.给ViewController提供数据
2.给ViewController存储数据提供接口
3.提供经过抽象的业务基本组件，供Controller调度

C应该做的事：
1.管理View Container的生命周期
2.负责生成所有的View实例，并放入View Container
3.监听来自View与业务有关的事件，通过与Model的合作，来完成对应事件的业务。

V应该做的事：
1.响应与业务无关的事件，并因此引发动画效果，点击反馈（如果合适的话，尽量还是放在View去做）等。
2.界面元素表达

• MVCS

苹果自身就采用的是这种架构思路，从名字也能看出，也是基于MVC衍生出来的一套架构。从概念上来说，它拆分的部分是Model部分，拆出来一个Store。这个Store专门负责数据存取。但从实际操作的角度上讲，它拆开的是Controller

这算是瘦Model的一种方案，瘦Model只是专门用于表达数据，然后存储、数据处理都交给外面的来做。MVCS使用的前提是，它假设了你是瘦Model，同时数据的存储和处理都在Controller去做。所以对应到MVCS，它在一开始就是拆分的Controller。因为Controller做了数据存储的事情，就会变得非常庞大，那么就把Controller专门负责存取数据的那部分抽离出来，交给另一个对象去做，这个对象就是Store。这么调整之后，整个结构也就变成了真正意义上的MVCS。

关于胖瘦Model

胖Model包含了部分弱业务逻辑。胖Model要达到的目的是，Controller从胖Model这里拿到数据之后，不用额外做操作或者只要做非常少的操作，就能够将数据直接应用在View上，比如说

<pre>
FatModel:
@property (nonatomic, assign) CGFloat timestamp;
- (NSString *)ymdDateString; // 2015-04-20 15:16
- (NSString *)gapString; // 3分钟前、1小时前、一天前、2015-3-13 12:34
</pre>

众所周知，强业务变动的可能性要比弱业务大得多，弱业务相对稳定，所以弱业务塞进Model里面是没问题的。另一方面，弱业务重复出现的频率要大于强业务，对复用性的要求更高，如果这部分业务写在Controller，类似的代码会洒得到处都是，一旦弱业务有修改（弱业务修改频率低不代表就没有修改），这个事情就是一个灾难。如果塞到Model里面去，改一处很多地方就能跟着改，就能避免这场灾难。

然而其缺点就在于，胖Model相对比较难移植，虽然只是包含弱业务，但好歹也是业务，迁移的时候很容易拔出萝卜带出泥。另外一点，MVC的架构思想更加倾向于Model是一个Layer，而不是一个Object，不应该把一个Layer应该做的事情交给一个Object去做。最后一点，软件是会成长的，FatModel很有可能随着软件的成长越来越Fat，最终难以维护。

瘦Model只负责业务数据的表达，所有业务无论强弱一律扔到Controller。瘦Model要达到的目的是，尽一切可能去编写细粒度Model，然后配套各种helper类或方法来对弱业务做抽象，强业务依旧交给Controller。举个例子

<pre>
SlimModel:
@property (nonatomic, strong) NSString *name;
@property (nonatomic, strong) NSString *sex;

Helper:
#define Male 1;
#define Female 0;
+ (BOOL)sexWithString:(NSString *)sex;
</pre>

由于SlimModel跟业务完全无关，它的数据可以交给任何一个能处理它数据的Helper或其他的对象，来完成业务。在代码迁移的时候独立性很强，很少会出现拔出萝卜带出泥的情况。另外，由于SlimModel只是数据表达，对它进行维护基本上是0成本，软件膨胀得再厉害，SlimModel也不会大到哪儿去。

缺点就在于，由于Model的操作会出现在各种地方，SlimModel在一定程度上违背了DRY（Don't Repeat Yourself）的思路，Controller仍然不可避免在一定程度上出现代码膨胀。

说回来，MVCS是基于瘦Model的一种架构思路，把原本Model要做的很多事情中的其中一部分关于数据存储的代码抽象成了Store，在一定程度上降低了Controller的压力。

• MVVM

MVVM是基于胖Model的架构思路建立的，然后在胖Model中拆出两部分：Model和ViewModel。关于这个观点我要做一个额外解释：胖Model做的事情是先为Controller减负，然后由于Model变胖，再在此基础上拆出ViewModel，跟业界普遍认知的MVVM本质上是为Controller减负这个说法并不矛盾，因为胖Model做的事情也是为Controller减负。

注意：MVVM的关键是要有View Model！而不是ReactiveCocoa

ViewModel做什么事情？

就是把RawData变成直接能被View使用的对象的一种Model。举个例子：

<pre>
Raw Data:
{
(
(123, 456),
(234, 567),
(345, 678)
)
}
</pre>

这里的RawData我们假设是经纬度，数字我随便写的不要太在意。然后你有一个模块是地图模块，把经纬度数组全部都转变成MKAnnotation或其派生类对于Controller来说是弱业务，（记住，胖Model就是用来做弱业务的），因此我们用ViewModel直接把它转变成MKAnnotation的NSArray，交给Controller之后Controller直接就可以用了。

那么ReactiveCocoa应该扮演什么角色？

不用ReactiveCocoa也能MVVM，用ReactiveCocoa能更好地体现MVVM的精髓。前面我举到的例子只是数据从API到View的方向，View的操作也会产生"数据"，只不过这里的"数据"更多的是体现在表达用户的操作上，比如输入了什么内容，那么数据就是text、选择了哪个cell，那么数据就是indexPath。那么在数据从view走向API或者Controller的方向上，就是ReactiveCocoa发挥的地方。

我们知道，ViewModel本质上算是Model层（因为是胖Model里面分出来的一部分），所以View并不适合直接持有ViewModel，那么View一旦产生数据了怎么办？扔信号扔给ViewModel，用谁扔？ReactiveCocoa。

在MVVM中使用ReactiveCocoa的第一个目的就是如上所说，View并不适合直接持有ViewModel。第二个目的就在于，ViewModel有可能并不是只服务于特定的一个View，使用更加松散的绑定关系能够降低ViewModel和View之间的耦合度。

那么在MVVM中，Controller扮演什么角色？

View <-> C <-> ViewModel <-> Model，所以使用MVVM之后，就不需要Controller的说法是不正确的。严格来说MVVM其实是MVCVM。
Controller夹在View和ViewModel之间做的其中一个主要事情就是将View和ViewModel进行绑定。在逻辑上，Controller知道应当展示哪个View，Controller也知道应当使用哪个ViewModel，然而View和ViewModel它们之间是互相不知道的，所以Controller就负责控制他们的绑定关系，所以叫Controller/控制器就是这个原因。

前面扯了那么多，其实归根结底就是一句话：在MVC的基础上，把C拆出一个ViewModel专门负责数据处理的事情，就是MVVM。然后，为了让View和ViewModel之间能够有比较松散的绑定关系，于是我们使用ReactiveCocoa，因为苹果本身并没有提供一个比较适合这种情况的绑定方法。iOS领域里KVO，Notification，block，delegate和target-action都可以用来做数据通信，从而来实现绑定，但都不如ReactiveCocoa提供的RACSignal来的优雅，如果不用ReactiveCocoa，绑定关系可能就做不到那么松散那么好，但并不影响它还是MVVM。

所以Controller在MVVM中，一方面负责View和ViewModel之间的绑定，另一方面也负责常规的UI逻辑处理。

• VIPER

八、拆分的心法

• 第一心法：保留最重要的任务，拆分其它不重要的任务

在iOS开发领域内，UIViewController承载了非常多的事情，比如View的初始化，业务逻辑，事件响应，数据加工等等，当然还有更多我现在也列举不出来，但是我们知道有一件事情Controller肯定逃不掉要做：协调V和M。也就是说，不管怎么拆，协调工作是拆不掉的。那么剩下的事情我们就可以拆了，比如UITableView的DataSource。这篇文章的第一节就提倡了这个做法。除了这篇文章提到的内容以外，任何比较大的，放在ViewController里面比较脏的，只要不是Controller的核心逻辑，都可以考虑拆出去，然后在架构的时候作为一个独立模块去定义，以及设计实现。

• 第二心法：拆分后的模块要尽可能提高可复用性，尽量做到DRY
  根据第一心法拆开来的东西，很有可能还是强业务相关的，这种情况有的时候无法避免。但我们拆也要拆得好看，拆出来的部分最好能够归成某一类对象，然后最好能够抽象出一个通用逻辑出来，使他能够复用。即使不能抽出通用逻辑，那也尽量抽象出一个protocol，来实现IOP。

+第三心法： 要尽可能提高拆分模块后的抽象度

也就是说，拆分的粒度要尽可能大一点，封装得要透明一些。提高抽象度事实上就是增加封装的力度，将一个负责的业务抽象成只需要很少的输入就能完成，就是高度抽象
提高抽象程度的好处在于，对于业务方来说，他只需要收集很少的信息（最小充要条件），做很少的调度（Controller负责大模块调度，大模块里面再去做小模块的调度），就能够完成任务，这才是给Controller减负的正确姿势。

如果拆分出来的模块抽象程度不够，模块对外界要求的参数比较多，那么在Controller里面，关于收集参数的代码就会多了很多。如果一部分参数的收集逻辑能够由模块来完成，那也可以做到帮Controller减轻负担。否则就感觉拆得不太干净，因为Controller里面还是多了一些不必要的参数收集逻辑。

如果拆分出来的粒度太小，Controller在完成任务的时候调度代码要写很多，那也不太好。导致拆分粒度小的首要因素就是业务可能本身就比较复杂，拆分粒度小并不是不好，能大就大一点，如果小了，那也没问题。针对这种情况的处理，就需要采用strategy模式。

针对拆分粒度小的情况，我来举个实际例子，这个例子来源于我的一个朋友他在做聊天应用的消息发送模块。当消息是文字时，直接发送。当消息是图片时，需要先向服务器申请上传资源，获得资源ID之后再上传图片，上传图片完成之后拿到图片URL，后面带着URL再把信息发送出去。

这时候我们拆模块，可以拆成：数据发送（叫A模块），上传资源申请（叫B模块），内容上传（叫C模块）。那么要发送文字消息，Controller调度A就可以了。如果要发送图片消息，Controller调度B->C->A，假设将来还有上传别的类型消息的任务，他们又要依赖D/E/F模块，那这个事情就很蛋疼，因为逻辑复杂了，Controller要调度的东西要区分的情况就多了，Controller就膨胀了。

那么怎么处理呢？可以采用Strategy模式。我们再来分析一下，Controller要完成任务，它初始情况下所具有的条件是什么？它有这条消息的所有数据，也知道这个消息的类型。那么它最终需要的是什么呢？消息发送的结果：发送成功或失败。

<pre>
send msg
Controller ------------------> MessageSender
^ |
| |
| |
----------------------------------
success / fail
</pre>

上面就是我们要实现的最终结果，Controller只要把消息丢给MessageSender，然后让MessageSender去做事情，做完了告诉Controller就好了。那么MessageSender里面怎么去调度逻辑？MessageSender里面可以有一个StrategyList，里面存放了表达各种逻辑的Block或者Invocation（Target－Action）。那么我们先定义一个Enum，里面规定了每种任务所需要的调度逻辑。

<pre>
typedef NS_ENUM (NSUInteger, MessageSendStrategy)
{
MessageSendStrategyText = 0,
MessageSendStrategyImage = 1,
MessageSendStrategyVoice = 2,
MessageSendStrategyVideo = 3
}
</pre>

然后在MessageSender里面的StrategyList是这样：

<pre>
@property (nonatomic, strong) NSArray *strategyList;

self.strategyList = @[TextSenderInvocation, ImageSenderInvocation, VoiceSenderInvocation, VideoSenderInvocation];

// 然后对外提供一个这样的接口，同时有一个delegate用来回调

• (void)sendMessage:(BaseMessage *)message withStrategy:(MessageSendStrategy)strategy;

@property (nonatomic, weak) id<MessageSenderDelegate> delegate;

@protocol MessageSenderDelegate<NSObject>

@required
- (void)messageSender:(MessageSender *)messageSender
didSuccessSendMessage:(BaseMessage *)message
strategy:(MessageSendStrategy)strategy;

  - (void)messageSender:(MessageSender *)messageSender
     didFailSendMessage:(BaseMessage *)message
               strategy:(MessageSendStrategy)strategy
                  error:(NSError *)error;

@end
</pre>

Controller里面是这样使用的：

<pre>
[self.messageSender sendMessage:message withStrategy:MessageSendStrategyText];
</pre>

MessageSender里面是这样的：
<pre>
[self.strategyList[strategy] invoke];
</pre>

然后在某个Invocation里面，就是这样的：
<pre>
[A invoke];
[B invoke];
[C invoke];
</pre>

这样就好啦，即便拆分粒度因为客观原因无法细化，那也能把复杂的判断逻辑和调度逻辑从Controller中抽出来，真正为Controller做到了减负。总之能够做到大粒度就尽量大粒度，实在做不到那也行，用Strategy把它hold住。这个例子是小粒度的情况，大粒度的情况太简单，我就不举了。

九、设计的心法

针对View层的架构不光是看重如何合理地拆分MVC来给UIViewController减负，另外一点也要照顾到业务方的使用成本。最好的情况是业务方什么都不知道，然后他把代码放进去就能跑，同时还能获得框架提供的种种功能。

• 第一心法：尽可能减少继承层级，涉及苹果原生对象的尽量不要继承
  继承是罪恶，尽量不要继承。虽然不可避免的是有些情况我们不得不从苹果原生对象中继承，比如UITableViewCell。但我还是建议尽量不要通过继承的方案来给原生对象添加功能，前面提到的Aspect方案和Category方案都可以使用。用Aspect＋load来实现重载函数，用Category来实现添加函数，当然，耍点手段用Category来添加property也是没问题的。这些方案已经覆盖了继承的全部功能，而且非常好维护，对于业务方也更加透明，何乐而不为呢。还能再多额外两个好处：1. 在业务方做业务开发或者做Demo时，可以脱离App环境，或花更少的时间搭建环境。2. 对业务方来说功能更加透明，也符合业务方在开发时的第一直觉

• 第二心法：做好代码规范，规定好代码在文件中的布局，尤其是ViewController

• 第三心法：能不放在Controller做的事情就尽量不要放在Controller里面去做

• 第四心法：架构师是为业务工程师服务的，而不是去使唤业务工程师的

十、总结

其实针对View层的架构设计，还是要做好三点：

• 代码规范
  制定良好的规范,代码规范对于View层来说意义重大，毕竟View层非常重业务，如果代码布局混乱，后来者很难接手，也很难维护。

• 架构模式
  选择好合适的模式（MVC、MVCS、MVVM、VIPER）
  架构模式具体如何选择，完全取决于业务复杂度。如果业务相当相当复杂，那就可以使用VIPER，如果相对简单，那就直接MVC稍微改改就好了。每一种已经成为定式的架构模式不见得都适合各自公司对应的业务，所以需要各位架构师根据情况去做一些拆分或者改变。拆分一般都不会出现问题，改变的时候，只要别把MVC三个角色搞混就好了，M该做啥做啥，C该做啥做啥，V该做啥做啥，不要乱来。关于大部分的架构模式应该是什么样子，这篇文章里都已经说过了，不过我认为最重要的还是后面的心法，模式只是招术，熟悉了心法才能大巧不工。

• 工具集
  根据业务情况针对ViewController做好拆分，提供一些小工具方便开发
  View层的工具集主要还是集中在如何对View进行布局，以及一些特定的View，比如带搜索提示的搜索框这种。这篇文章只提到了View布局的工具集，其它的工具集相对而言是更加取决于各自公司的业务的，各自实现或者使用CocoaPods里现成的都不是很难。

架构师要做针对View层的方案时，最好还是尽量遵守苹果已有的规范和设计思想，然后根据自己过去开发iOS时的经验，尽可能给业务方在开发业务时减负，提高业务代码的可维护性，就是View层架构方案的最大目标

对于小规模或者中等规模iOS开发团队来说，做好以上三点就足够了。在大规模团队中，有一个额外问题要考虑，就是跨业务页面调用方案的设计。

十一、跨业务页面调用方案的设计

跨业务页面调用是指，当一个App中存在A业务，B业务等多个业务时，B业务有可能会需要展示A业务的某个页面，A业务也有可能会调用其他业务的某个页面。在小规模的App中，我们直接import其他业务的某个ViewController然后或者push或者present，是不会产生特别大的问题的。但是如果App的规模非常大，涉及业务数量非常多，再这么直接import就会出现问题。

<pre>
-------------- -------------- --------------
| | page call | | page call | |
| Buisness A | <---------> | Buisness B | <---------> | Buisness C |
| | | | | |
-------------- -------------- --------------
\ | /
\ | /
\ | /
\ | /
\ | /
--------------------------------
| |
| App |
| |
--------------------------------
</pre>

可以看出，跨业务的页面调用在多业务组成的App中会导致横向依赖。那么像这样的横向依赖，如果不去设法解决，会导致什么样的结果？

1.当一个需求需要多业务合作开发时，如果直接依赖，会导致某些依赖层上端的业务工程师在前期空转，依赖层下端的工程师任务繁重，而整个需求完成的速度会变慢，影响的是团队开发迭代速度。

2.当要开辟一个新业务时，如果已有各业务间直接依赖，新业务又依赖某个旧业务，就导致新业务的开发环境搭建困难，因为必须要把所有相关业务都塞入开发环境，新业务才能进行开发。影响的是新业务的响应速度。

3.当某一个被其他业务依赖的页面有所修改时，比如改名，涉及到的修改面就会特别大。影响的是造成任务量和维护成本都上升的结果。

当然，如果App规模特别小，这三点带来的影响也会特别小，但是在阿里这样大规模的团队中，像天猫／淘宝这样大规模的App，一旦遇上这里面哪怕其中一件事情，就特么很坑爹。

那么应该怎样处理这个问题？
让依赖关系下沉。

怎么让依赖关系下沉？引入Mediator模式。

所谓引入Mediator模式来让依赖关系下沉，实质上就是每次呼唤页面的时候，通过一个中间人来召唤另外一个页面，这样只要每个业务依赖这个中间人就可以了，中间人的角色就可以放在业务层的下面一层，这就是依赖关系下沉。

<pre>
-------------- -------------- --------------
| | | | | |
| Buisness A | | Buisness B | | Buisness C |
| | | | | |
-------------- -------------- --------------
\ | /
\ | /
\ | / 通过Mediater来召唤页面
\ | /
\ | /
--------------------------------
| |
| Mediater |
| |
--------------------------------
|
|
|
|
|
--------------------------------
| |
| App |
| |
--------------------------------
</pre>

当A业务需要调用B业务的某个页面的时候，将请求交给Mediater，然后由Mediater通过某种手段获取到B业务页面的实例，交还给A就行了。在具体实现这个机制的过程中，有以下几个问题需要解决：

1. 设计一套通用的请求机制，请求机制需要跟业务剥离，使得不同业务的页面请求都能够被Mediater处理
2. 设计Mediater根据请求如何获取其他业务的机制，Mediater需要知道如何处理请求，上哪儿去找到需要的页面