设计模式

设计模式 和 编码技巧 、架构模式的区别：

• 设计模式：特定场景下的最佳实践 如： MVC MVVM MVP。

• 编码技巧：单例模式、工厂模式等

• 架构模式：包括网络模块实现、数据存储模块实现、业务逻辑模块实现分离复用等

架构模式 > 设计模式 > 编码技巧

• 继承
• 关联
• 组合
• 聚合

MVC

• 用户触发View交互，传递数据给Controller，controller接收UI更改信号去更改Model，再将Model传递给View 更新View；
• 当然 如有特殊需求 也能实现一些反向的数据通信：View 更改Model，传递给Controller，controller去更改View

由此可见：整个UI更新过程，数据是单向(环状)传递的

环状这就导致了，类与类之间交互复杂，业务逻辑的耦合度会很高

解重

• Present：处理数据初始化、数据组合、数据过滤 UI 交互传值 delegate
• dataSource：传入CellIdentity ，以及model

Controller 跟present交互 Model 跟 present交互 present作为中心逻辑处理

解耦

• 子UI组件 刷新UI的时候大都会有这个方法:

-(void) loadModel:(BaseModel *)model;

这样，每次在复用UI组件的时候不得已，可能还得复用Model。如果跨项目，复用Model就可能不太合理了，那么我们在刷新UI的时候 尽可能的载入进本的更该数值 而并非 笨重的Model。

• MVC 中环形的数据传递，必然导致 文件的相互包含，相互引用、相互依赖问题，MVP模式中把依赖都挪到了present 是一个比较好的选择。

MVP

• 优点： View组件很薄，处理的逻辑很少，不需要持有任何的Model文件的引用，复用的时候直接copy View组件进去就能用；传统的MVC中都是Model去驱动View ，View组件中都会引用Model，耦合度高改了model就得改View ，改了View ，model也可能需要更改。
• 缺点：present 作为中间人，需要交互的内容太多，逻辑很重

MVVM

• MVVM： Model 、View 依旧是互不通信，跟MVP类似， 唯一不同就是View和ViewModel是双向绑定的关系，并非双向通信，比双向通信关系更紧密ViewModel跟 model 是双向通信的关系，没有ViewModel 跟View关系那么紧密

总结

MVP 、MVVM 其实都是MVC发展而来的，三种设计模式没有孰优孰劣，只有哪个更适合。

个人总结对比：

• MVC：相对灵活，简单，容易掌握，数据传递比较直接。更适合轻量级的项目。
• MVP：有了一定的规则，present 集中处理业务逻辑，一定程度上减少了耦合度，中小型项目都还比较合适
• MVVM：写起来听复杂的，每个View对应一个ViewModel，对于成型的稳定的大项目来说，还是很适合的，一定程度上降低了耦合度不会直接操作View 和 Model 而是操作ViewModel 去更改View 更改Model，耦合度低，较为灵活。 Model 、View、ViewModel三者之间关系以及各自作用熟悉了以后，还是很清晰的。