调用网络API
页面展示
数据的本地持久化
动态部署方案

那么需要解决的问题

• 网络层设计方案？
  设计网络层需要考虑哪些问题？
  网络层的优化从哪里入手？

• 页面展示层设计方案？
  页面的展示，调用，组织都有哪些设计方案

• 本地持久化的设计方案有哪些？

• 要实现动态部署，都有哪些方案

软件架构的思路

1. 要解决的问题（问题是什么）
2. 问题分类，用不同的模块解决不同类型的问题
3. 搞清楚各个问题之间的依赖关系
4. 推演预测未来可能的走向
5. 先实现基础模块，在用基础模块堆积整个架构

View层的组织和调用方案

架构模式

1. 如何划分MVC
   M,V,C
   在服务端的开发中V主要是指浏览器。
   在iOS开发中V主要是指self.view的容器

2. MVCS
   将C的数据储存部分抽离出来，交给另一个对象去做，即store

3. MVVM
   将C的数据处理部分抽离出来，交给viewModel处理。即vm
   而C负责View与ViewModel之间的绑定，以及UI逻辑处理

4. VIPER
   (不懂)

总结：这些架构都是在MVC的基础上拆分出来的。天下架构出MVC，拆分方式的不同衍生出不同的架构。

是否应该使用BaseViewController？

尽可能不使用继承而是使用组合或者面向切面编程的AOP来替代。

• 好处
• 业务方集成成本小。（因为如果用了继承会导致，在集成到其他APP里时，需要依赖很多东西，打动干戈）
• 新用户上手接收成本也减少了

• 架构维护成本低

• 目标

• 业务方可以不用继承的方法，然后框架能够做到ViewController的统一配置。

• 业务方即使脱离框架环境，

解耦定义

代码里不相互依赖，依赖分两种，单向依赖，双向依赖。

组件化的定义

让高层模块单向依赖低层模块，业务模块之间完全解耦

解耦的几种方式

1. 代理
2. block
3. 通知
4. kvo

组件通信实现

1. runtime反射机制在Mediator里的实现，在通过对Mediator的category进行接口分离(本质是runtime的反射机制)
2. 通过在Mediator里注册block,一般是进行url与block的映射（本质是存block）
3. 同过在Mediator里注册protocal（本质是存class）

总结下：业务层可以依赖基础库，但业务层要相互不依赖。就需要依赖一个可以连接两个业务层的东西Mediator。为了防止业务层又与Mediator相互依赖。这里只允许业务层单向依赖Mediator。其实解耦可以是任意两个类之间实现单向依赖。只是将解耦应用到了对Mediator的单向依赖上。

组合与继承的选择

组合与继承都可以实现代码的复用
1. 除非两个类之间是"is-a"的关系，否则不要轻易使用继承
2. 两个类之间是has a的关系时，最好用组合