iOS 架构MVP,MVVM浅谈

iOS 架构设计

1.概述

iOS 开发中，MVC（Model View Controller）是构建iOS App的标准模式，是苹果推荐的一个用来组织代码的权威范式，iOS自己的库基本都是这个模式，而它的缺点如下：

• ViewController代码厚重
• 功能模块划分混乱
• 可测试性差

随着工程越来越大也表现得更加明显，继而MVVM，MVP等架构设计流行起来;通过这个简单 demo 结合类图可以清晰的看出MVVM和MVP架构设置的特点。

2.MVVM

pg1.png

mvc中的model，添加业务逻辑成胖model，再添加操作数据的接口就成了viewmodel，旨在返回UI控件可以直接使用的数据，需求改动后只需改动viewmodel中生成数据的逻辑即可

思路：

• view 引用viewModel，返回view的可用数据 ，但反过来不行（即不要在viewModel中引入#import UIKit.h，任何视图本身的引用都不应该放在viewModel中）
• viewModel 引用model，但反过来不行
• viewController 尽量不涉及业务逻辑，让 viewModel 去做这些事情

优势：

• View可以独立于Model变化和修改，一个 viewModel 可以绑定到不同的 View 上
• 开发人员可以专注于业务逻辑和数据的开发(viewModel)，设计人员可以专注于页面设计
• 通常界面是比较难于测试的，而 MVVM 模式可以针对 viewModel来进行测试

弊端：

• 数据绑定使得Bug 很难被调试，有可能是View的代码问题，也可能是 Model的代码有问题
• 对于过大的项目，数据绑定需要花费更多的内存。

3.MVP

pg2.png

mvc中的view，添加特定的UI交合逻辑，变成自定义view，再添加数据的填充逻辑就变成了presenter

思路：

• 将Controller中某一UI模块单独抽取一个presenter类，将这个模块的UI控件操作及数据处理封装其中，以delegate方式通知Controller它需要关心的事件
• Controller其实将view和viewController传递给了P层, 这样P层其实就拥有了控制器的权利, 完全可以行使控制器的职责.
• Controller又持有Presenter, 那么它只需要调用P层暴露出的接口, 就完全可以完成整个业务逻辑和页面展示
• Controller只负责控制页面跳转，调用其它模块。
• 任务均摊，我们将最主要的任务划分到 Presenter 和 Model，而 View 的功能较少

优势：

• 模块化UI组件，Controller结构更加清晰，责任更单一，只需关注各个大模块的调用
• UI组件复用好

弊端：

• presenter之间的交互比较困难，模块抽取粒度衡量难度大

4.总结

MVVM，MVP各个有各自的优缺点，主要职责是减少Controller里面的代码量

• MVVM通过抽取业务数据逻辑而减少Controller的代码
• MVP通过模块化各个UI组件来减少Controller的代码