iOS 中架构模式的浅显理解

我们开发软件中应用各种模式,主要是为了

  1. 职责划分:一个类只做一件事
  2. 易用,可维护,方便扩展
  3. 解耦,相互独立,可单独测试

各种设计模式其实都是在解决上面的问题,让我们对比看看吧。

一、如何理解MVC设计模式

在通常的定义中,MVC 是下图的结构

但是在 cocoa 体系中,苹果建议的 MVC 模式如下图所示

在斯坦福课程中,解释的 MVC 如下图所示

综合一下在 cocoa 系统中可以这么理解:

  • M model,存储、定义、操纵数据
  • V view,用户看到的UI,能够和用户交互
  • C controller,协调者,把 model 的数据放到 view 中展示,相应 view 的交互改变 model
    特别在 cocoa 系统中
    C 持有一个 model,直接操作 model;model 通过 KVO、通知等方式抛出自己改变的事件
    C 通过 IBOutlet 或者直接持有一个 view,他可以直接操作这个view;view 有了交互,可以通过action target 方式 以及 delegate 方式 让 controller 来响应事件,但是 view 并不知道具体是哪个类对象;view 的需要的数据,可以通过 protocol 的方式,让 controller 实现这个 protocol 并且成为 view 的数据源,来提供数据给 view,view并不需要知道 controller 的具体的类对象。

最简单的例子就是 UITableviewController,他一般会持有一个 NSArray 作为 model,同时根视图就是一个 UITableView,这是 view。controller 从网络或者本地加载数据赋值给 array,然后 reload tableview。tableview 绘制时请求数据源,相应用户事件会通过delegate 发起调用。tableview 与 array 并没有直接的关系。

进一步的,如果我的页面很复杂,那么这个 MVC 是怎么处理的呢?看看斯坦福的另一张讲义:

也就是 cocoa 中,Controlelr 控制的 view 可以是属于别的 MVC 中的,最外层的 MVC 来管理这些子 MVC。所以最好不要一个 C 中对应多个 view 或者 model,而是需要拆分成多个 MVC 来。

缺点:

  1. 如果严格按照MVC模式的话,不像 view 传递 model,那么代码就会臃肿,想象往一个cell 设置用户信息,单独传一个 userModel,然后 cell 内部处理会很简洁,如果分开在controller 里面传 头像、姓名、签名,就会很臃肿
  2. view 和 controller 一般都是绑定在一起的,生命周期的控制依赖于 controller,独立测试会很不方便

二、MVP 模式

基于 MVC 的缺点和优点,既然 view 和 cocoa 中的 viewController 已经那么强的紧密耦合了,那么把这两者看成同一个东西,一起做为一个 view 。
Model 层负责数据的增删改查(网络,数据库查询,本地文件读写)。
Presenter 层只是一个中介,负责数据的转发。

上图展示的是 View 持有 Presenter,Presenter 持有 Model。所以 Presenter 不依赖于具体的 View,这个可以通过 Protocol 来实现,让 View 实现一些数据更新的协议,presenter 就可以不知道View 具体是什么就能传递数据。

优点:
每一层的任务互相独立分开了,让测试更加方便。

** 缺点:**
代码量会提升很多。

示例见参考2.参考2的复杂MVP可以简化如下图所示:

三、MVVM 模式

MVP 的 Presenter 需要主动更新 view,如果增加一个绑定机制呢,model 的改变及时反馈在 view上会不会更酷。但是这样就会让 model 和 view 关联起来,所以就出来一个 viewModel 的东西。

ViewModel 持有 Model,管理 Model 并可以把 Model 中的数据处理成 View 需要的数据。同时可以处理用户输入验证逻辑,视图显示逻辑,发起网络请求和其他各种各样的代码。
View 持有 ViewModel,并且和 ViewModel 中的数据绑定,让 ViewModel 中的数据改变及时反应在 View上;并且把一些按钮事件的 target 设置给 ViewModel。

优点:

  • View Model 的引入配合状态流和响应式编程使得 App 的结构更加清晰,交互更加流畅。
  • MVVM 中的 View 责任多一点,因为要设置绑定,但也因为绑定,所以代码量更少。测试时主要是测试 View Model 和 Model 。

缺点:
因为数据的双向绑定,让BUG的定位更加困难,过大的项目也会耗费更多的内存。

四、VIPER 模式

VIPER 其实是 MVP 的一种扩展,VP不变,M变成了 Interactor 和 Entity,外加一个 Routing。Entity 就是 model 的数据结构, Interactor 就是处理 model 的类,增删改查model,Routing 就是控制视图的跳转。可以看到 viper 模式分的更细,每层的功能更明确,更容易测试。但是也更复杂,代码量也会更加庞大。

可以参考下面两个图结构图。
图一:

图二:

参考1.https://www.objc.io/issues/13-architecture/mvvm/
参考2.https://github.com/amacou/MVPExample
参考3.https://www.objc.io/issues/13-architecture/viper/

原文地址:https://www.cnblogs.com/v2m_/p/7282820.html