调用网络API
页面展示
数据的本地持久化
动态部署方案
那么需要解决的问题
网络层设计方案？
设计网络层需要考虑哪些问题？
网络层的优化从哪里入手？页面展示层设计方案？
页面的展示，调用，组织都有哪些设计方案本地持久化的设计方案有哪些？
要实现动态部署，都有哪些方案
软件架构的思路
- 要解决的问题（问题是什么）
- 问题分类，用不同的模块解决不同类型的问题
- 搞清楚各个问题之间的依赖关系
- 推演预测未来可能的走向
- 先实现基础模块，在用基础模块堆积整个架构
View层的组织和调用方案
架构模式
如何划分MVC
M,V,C
在服务端的开发中V主要是指浏览器。
在iOS开发中V主要是指self.view的容器MVCS
将C的数据储存部分抽离出来，交给另一个对象去做，即storeMVVM
将C的数据处理部分抽离出来，交给viewModel处理。即vm
而C负责View与ViewModel之间的绑定，以及UI逻辑处理VIPER
(不懂)
总结：这些架构都是在MVC的基础上拆分出来的。天下架构出MVC，拆分方式的不同衍生出不同的架构。
是否应该使用BaseViewController？
尽可能不使用继承而是使用组合或者面向切面编程的AOP来替代。
- 好处
- 业务方集成成本小。（因为如果用了继承会导致，在集成到其他APP里时，需要依赖很多东西，打动干戈）
- 新用户上手接收成本也减少了
架构维护成本低
目标
业务方可以不用继承的方法，然后框架能够做到ViewController的统一配置。
业务方即使脱离框架环境，
解耦定义
代码里不相互依赖，依赖分两种，单向依赖，双向依赖。
组件化的定义
让高层模块单向依赖低层模块，业务模块之间完全解耦
解耦的几种方式
- 代理
- block
- 通知
- kvo
组件通信实现
- runtime反射机制在Mediator里的实现，在通过对Mediator的category进行接口分离(本质是runtime的反射机制)
- 通过在Mediator里注册block,一般是进行url与block的映射（本质是存block）
- 同过在Mediator里注册protocal（本质是存class）
总结下：业务层可以依赖基础库，但业务层要相互不依赖。就需要依赖一个可以连接两个业务层的东西Mediator。为了防止业务层又与Mediator相互依赖。这里只允许业务层单向依赖Mediator。其实解耦可以是任意两个类之间实现单向依赖。只是将解耦应用到了对Mediator的单向依赖上。
组合与继承的选择
组合与继承都可以实现代码的复用
1. 除非两个类之间是"is-a"的关系，否则不要轻易使用继承
2. 两个类之间是has a的关系时，最好用组合