架构就如人体骨架，肌肉和血液还有其他就顺着骨架填充！
MVC架构思想
MVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。
组成MVC的三个模式分别是组合模式、策咯模式、观察者模式，MVC在软件开发中发挥的威力，最终离不开这三个模式的默契配合
- View层，单独实现了组合模式
- Model层和View层，实现了观察者模式
- View层和Controller层，实现了策咯模式
MVC要实现的目标是将软件用户界面和业务逻辑分离以使代码 可扩展性、可复用性、可维护性、灵活性加强.
ViewController过重
通过上面的图大家也看到了非常完美，但是用起来真有问题！
但是我们实际开发经常会变形：比如我们ViewController会非常之重，动不动几百行，几千行代码！那么是一些什么东西在里面？
- 繁重的网络层
- 复杂的UI层
- 难受的代理
- 啰嗦的业务逻辑
- 还有一些其他功能
控制器（controller）的作用就是这么简单， 用来将不同的View和不同的Model组织在一起，顺便替双方传递消息，仅此而已。
这里建议：
- 繁重的网络层 封装到我们业务逻辑管理者比如：
presentviewModel - 复杂的UI层就应该是UI的事，直接剥离出VC
-
难受的代理就可以封装一个功能类比如我们常写的tableview collectionView的代理 我们就可以抽取出来封装为一个公共模块，一些特定的逻辑就可以利用适配器设计模式，根据相应的model消息转发
耦合性问题
经常我们在开发过程中会出现下面的线！
这样的线对我们重用性，灵活性造成了压力
这里我推荐大家使用不直接依赖model 利用发送消息的方式传递
MVP架构思想
MVP 全称：Model-View-Presenter ；MVP 是从经典的模式MVC演变而来，它们的基本思想有相通的地方：Controller/Presenter负责逻辑的处理，Model提供数据，View负责显示。
我最喜欢MVP的面向协议编程的思想！
根据产品相应的需求，写出其次需求的接口，然后根据接口去找我们响应的发起者，和接受者！面向协议编程---面向接口编程---面向需求编程---需求驱动代码！
MVP能够解决：
- 代码思路清晰
- 耦合度降低显著
- 通讯还算比较简单
缺点：
- 我们需要写很多关于代理相关的代码
- 视图和Presenter的交互会过于频繁
- 如果Presenter过多地渲染了视图，往往会使得它与特定的视图的联系过于紧密。一旦视图需要变更，那么Presenter也需要变更了
MVVM架构思想
MVVM是Model-View-ViewModel的简写。它本质上就是MVC 的改进版。MVVM 就是将其中的View 的状态和行为抽象化，让我们将视图 UI 和业务逻辑分开。当然这些事 ViewModel 已经帮我们做了，它可以取出 Model 的数据同时帮忙处理 View 中由于需要展示内容而涉及的业务逻辑
如果要说MVVM的特色，我觉得最大莫过于：双向绑定
经常我们在设计我们的架构的时候，ViewModel层会设计响应的反向Block回调，方便我们的数据更新，只需要我们回调Block,那么在相应代码块绑定的视图中就能获取到最新的数据！
这个时候我们要向完美实现正向传递，经常借助另一个非常牛逼的思想：响应式
如果要想完美实现双向绑定，那么KVO我不太建议,推荐玩玩ReactiveCocoa这个框架---编程思想之集大成者！如果你们在MVVM架构设计中嵌入响应式，那就是双剑合璧.
组件路由设计
在众多架构中，在解耦性方面我觉得组件化开发无意做的真心不错，大家经常在各个控制器跳转，就会像蜘蛛网一样错综复杂。
站在架构的层面就是把项目规矩化！条理化
根据合适的边界把这个项目进行组件模块化出来，利用cocoaPods来管理！在整体组件分层下面的模型给大家进行参考学习！
架构之路，无论在知识的深度还有广度方面都有较高的要求！尤其重要的对问题的的解决思维，不止在普通的应用层的ipa调用；需要大家对思维更加宽广，从代码上升到项目，到产品，甚至到公司！有时候你会很感觉很累很难，但是不将就注定不一样的你！
