IOS项目中几个常见的架构（MVC等）

一、MVC

001 概念 Model-view-controller 

View：管理作为位图展示到屏幕上的图形和文字输出

Controller：翻译用户的输入并依照用户的输入操作和视图

Model：管理应用的行为和数据，响应数据请求和更新状态的指令

来源

002 特点

优势：分离视图层和模型层之间的耦合，作为数据存储功能的模型层，可以通过控制器同时为多个不同视图提供数据

GUI应用程序可以分成两个部分：一部分用于展现内容的展现层。另一部分包含领域层和数据逻辑层

Presentation---Domain，展示层依赖于领域层中存储，而领域层对展示层一无所知。MVC 最重要的目的是将原有混乱的应用程序划分成合理的层级，。

观察者同步：当model中数据发生改变，需要将数据同步到多个View和ViewController，但是哟个缺点就是由于时间触发的隐式行为

可能导致很难查找问题的来源并影响其解决。

App和服务器一起组成一个更大的MVC架构，服务器的Model层才是存储了真正的数据，二客户端的model层只是不一个缓存数据集合，服务端的视图层的数据仅仅用于展示在客户端；中间的五部分，从低端的model层到最上面的View共同组成应用的ViewController，将模型中数据以合理的方式传递给最上层的视图层用于展示。

二、MVP

001 概念

MVC的变种，主要区别在于MVP使用Presenter对视图和模型进行接耦，让它们彼此都不知道，沟通通过Presenter进行。

Presenter可以理解成松散的控制器，其中包含了视图的UI业务逻辑，所有从视图出发的事件，都会通过代理给Presenter进行处理，同时Presenter也通过视图暴露的接口与其进行通信。

002 常见两个类型

Passive View（被动视图）：视图是被动的，它本身不会改变自己任何状态，所有的状态都通过Presenter的间接改变

视图成了完全被动且不再根据模型来更新视图本身的内容，视图层对于模型没有任何的依赖。

通行方式：模型的操作以及视图更新都通过Presenter作为中间人进行。

1. 当视图接收到来自用户的事件时，会将事件转交给 Presenter 进行处理；
2. 被动的视图向外界暴露接口，当需要更新视图时 Presenter 通过视图暴露的接口更新视图的内容；
3. Presenter 负责对模型进行操作和更新，在需要时取出其中存储的信息；
4. 当模型层改变时，可以将改变的信息发送给观察者 Presenter；

Supervising Controller（监督视图）

不同于被动视图中状态同步都需要显式操作，监督控制器就将部分需要显式同步的操作变成了隐式。

在监督控制器中，视图层接管了一部分视图逻辑，主要内容就是同步简单的视图和模型的状态；而监督控制器就需要负责响应用户的输入以及一部分更加复杂的视图、模型状态同步工作。

通信方式：增加了视图和模型层之间增加了耦合性，也增加了架构的复杂性。

视图和监督控制器、模型与监督控制器的关系与被动视图中两者与 Presenter 的关系几乎相同，视图和模型之间新增的依赖就是数据绑定的产物；视图通过声明式的语法与模型中的简单属性进行绑定，当模型发生改变时，会通知其观察者视图作出相应的更新。

通过这种方式能够减轻监督控制器的负担，减少其中简单的代码，将一部分逻辑交由视图进行处理；这样也就导致了视图同时可以被 Presenter 和数据绑定两种方式更新，相比于被动视图，监督控制器的方式也降低了视图的可测试性和封装性。

三、MVVM

001 概念 模型-视图-视图模型

002 Binder层

声明式的数据和命令的绑定通过binder层完成，处理视图和模型之间状态的同步。

无论是 MVVM 还是 Presentation Model，其中最重要的不是如何同步视图和展示模型/视图模型之间的状态，是使用观察者模式、双向绑定还是其它的机制都不是整个模式中最重要的部分，最为关键的是展示模型/视图模型创建了一个视图的抽象，将视图中的状态和行为抽离出一个新的抽象，这才是 MVVM 和 PM 中需要注意的。

四、总结

从 MVC 架构模式到 MVVM，从分离展示层到展示模型层，经过几十年的发展和演变，MVC 架构模式出现了各种各样的变种，并在不同的平台上有着自己的实现。

在架构模式的选用时，我们往往没有太多的发言权，主要因为平台本身往往对应用层有着自己的设计，我们在开发客户端或者前端应用时，只需要遵循平台固有的设计就可以完成应用的开发；不过，在有些时候，由于工程变得庞大、业务逻辑变得异常复杂，我们也可以考虑在原有的架构之上实现一个新的架构以满足工程上的需要。

各种架构模式的作用就是分离关注，将属于不同模块的功能分散到合适的位置中，同时尽量降低各个模块的相互依赖并且减少需要联系的胶水代码。

参考资料