移动iOS架构起航

架构就如人体骨架，肌肉和血液还有其他就顺着骨架填充！

MVC架构思想

MVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。

组成MVC的三个模式分别是组合模式、策咯模式、观察者模式，MVC在软件开发中发挥的威力，最终离不开这三个模式的默契配合

View层，单独实现了组合模式

Model层和View层，实现了观察者模式

View层和Controller层，实现了策咯模式

MVC要实现的目标是将软件用户界面和业务逻辑分离以使代码 可扩展性、可复用性、可维护性、灵活性加强.

ViewController过重

通过上面的图大家也看到了非常完美，但是用起来真有问题！

但是我们实际开发经常会变形：比如我们ViewController会非常之重，动不动几百行，几千行代码！那么是一些什么东西在里面？

繁重的网络层

复杂的UI层

难受的代理

啰嗦的业务逻辑

还有一些其他功能

控制器（controller）的作用就是这么简单， 用来将不同的View和不同的Model组织在一起，顺便替双方传递消息，仅此而已。

这里建议：

繁重的网络层 封装到我们业务逻辑管理者比如：present viewModel

复杂的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架构设计中嵌入响应式，那就是双剑合璧.

组件路由设计