iOS 开发中的 ViewModel

MVVM 这个模式可能大家耳朵都听出茧了,但却没有多少人真正在项目中应用过,毕竟 Cocoa Touch 整体是基于“MVC”的,没有 Controller 根本干不了活。而且这年头虽然各种 buzz word 盛嚣尘上,但不同领域的人对它们都有不同的理解,看多了说多了自己都有点烦。我今天也不想说到底什么是 MVC,什么是 MVVM,这些我之前在这篇文章有提过一点。如果大家真的对它们的原始定义感兴趣,可以看看这篇 MVC 论文,四人帮的《设计模式》也对 MVC 有所阐述;MVVM 的话我们知道它是微软在推出 WPF 时提出的,可以看看 MSDN 的相关博客

言归正传,今天我主要想谈谈自己对 ViewModel 的一些理解。因为我们不一定要完全照搬某种模式,取其精华然后根据具体项目情况进行应用也挺好的。ViewModel 这个概念我就觉得蛮精华的。我们都知道 ViewModel 跟 View 是绑定的关系,那究竟怎么绑定呢?有几种方案:

  • UI 布局尽量用 IB 来做,把绑定逻辑放到 View 中
  • 把绑定逻辑放到 Model 中
  • 定义单独的 ViewModel 加工 Model,并把适合展示的数据输出给 View

以上这几种方案主要说的是数据绑定,而且都是单向绑定,实际上 ViewModel 还可以跟 View 进行双向数据绑定、逻辑绑定等,这些先按下不表,下面举个例子分别说说这三种单向数据绑定的实现以及优缺点。

626506-e9f0ec4fc8bfe938

Profile.png

上图是我正在写的一个 Github 客户端的 Profile 页面,它的头部是一个单独的 View,包含了一些 UI 元素:

通过网络请求拿到相关数据之后,怎么传递给这些 UI 元素来显示呢?当然我们可以放到 Controller 中,只不过 Controller 会变得非常臃肿。那我们就来尝试以上三种方案。

方案一:View 作为 ViewModel

这个是我以前比较喜欢的做法,优点是简洁明了,没有太多弯弯绕绕的东西,基本就是把原本写在 Controller 中的代码放到了 View 中。缺点也非常明显,就是这个“绑定”实在是绑得太死了,直接就写在了 View 里,那这个 View 基本就不能复用了。假设在另一个页面也有一个 Header,UI 跟这个ProfileHeader一样,展示的数据也是来自Profile这个 Model,但是展示的方式不一样,譬如nicknameLabel需要显示 Nickname: XXX,其它 UI 元素也需要加点附加信息什么的,那这个时候就很尴尬了。只能新建一个NewHeader,把之前的 xib 文件 copy 过来,把 class 改成NewHeader,把各个 label 啊 button 啊拉线拉过来,然后写一个新的bind方法。如果ProfileHeader中有很多其它的辅助方法,在NewHeader中也要用到,那NewHeader就得继承ProfileHeader,然后重写bind方法……所以这种方案啊,是不太科学的……想必你也发现了,这种情况下,ViewModelType这个协议,其实并没有什么卵用。用协议作为类型,往往可以提供更大的灵活性和可扩展性,但是如果是由 View 来实现这个协议,由于 View 已经是数据流的终点了,一旦把处理数据的逻辑写在这里,就不存在什么替换的可能了,这个协议也就只是作为一个限制或者说标识了——一旦别人看到某个 View 实现了这个协议,就知道这个 View 内部有处理数据的逻辑。但按这个思路的话,其实基本每个 View 都需要处理数据,也就都需要实现这个协议。所以这个协议其实是可有可无的,它的存在除了让代码显得更“面向协议(POP)”一些,并没有带来太多实质性的好处。

方案二:Model 作为 ViewModel

这种方案我在一个演讲中看到过,思路也很简单,跟方案一恰恰相反,不是把 Model 注入 View 中,而是把 View 注入 Model 中,还是以 Profile 为例:

这个方案呢,看着花哨了一些,View 的复用性也提高了。但是它的局限其实跟方案一是差不多的,方案一是可以复用 Model,但 View 的复用性不高;而方案二恰恰相反,View 的复用性提高了,但 Model 不好复用……数据加工的逻辑写在 Model 的renderInContext方法中,一旦有业务场景需要不同的数据加工逻辑,就要新建一个 Model 或者继承Profile。而众所周知继承在 Swift 中是不被提倡的,我这边声明的Profile是个struct,是不能被继承的,所以这种方案也并不是最合适的方案。

方案三:定义单独的 ViewModel 加工 Model,并把适合展示的数据输出给 View

软件设计有个重要的原则——封装变化,分析前面两个方案的局限性,我们可以明确的知道,“数据加工”是一个比较容易变化的点,而 View 和 Model 相对来说要稳定一些。那我们就把“数据加工”这个逻辑单独封装起来,把变化的部分和不变的部分隔离,这样 View 和 Model 的复用性就都提高了。

这个 ViewModel 以一个 Model 为输入,以一些可以直接被 View 使用的数据为输出。然后我们把它注入到 View 中即可,注入的方式无所谓,无论是作为初始化参数,抑或是作为属性或者方法参数等等,都可以,只要它是能被外部注入的,而不是由 View 自己生成的即可。譬如把它作为属性:

这样我们就可以声明多个 ViewModel,它们都遵守 ViewModelType,要展示不同数据的时候,只要赋给ProfileHeader不同的 ViewModel 就行了。

扩展思考

其实 View 是可以非常通用的,譬如ProfileHeaderView这个 View 不一定是用在 Profile 模块中,也可以用在 Repository 模块中(只是举个例子,一般 Repository 模块不会用这样的 Header 吧……)。那中间的avatarView就不是用来显示头像,而是显示项目的 Logo,backgroundView也显示 Logo,nicknameLabel用来显示项目名,bioLabel显示项目描述等等,这个时候你就会发现ProfileHeaderView包括内部 UI 元素的那些命名都是不合适,跟具体业务耦合得太紧了。如果这个 Header 是到处都可能用到的,那命名就应该是CustomHeaderViewcenterImageViewtopLabel之类的跟业务无关的形式。这个时候对应的 ViewModel 只要保证输出是直接可以被使用数据即可,输入并不一定要是Profile,也可以是Repository,甚至不一定要是 Model,也可以是 Dictionary 、JSON 等等。但是越通用,往往可读性就越低,很显然nicknameLabeltopLabel要好懂得多;越通用,往往中间层就越多,模块间的关系就越不直观。所以在封装变化的时候,要确保抽象出来封装的内容是真的有可能变化的,否则就成了过度设计。譬如 ViewModel 这个东西,如果你的 View 是一个高度定制化的 View,几乎没有被复用的可能,那在命名的时候,大可以跟业务相关,数据处理也可以采用方案一,因为这是最容易理解的方式,也是最方便开发的方式。这世上很少有放之四海皆准的道理,还是要结合具体情况多思考权衡吧。

RxSwift + MVVM

由于 Cocoa Touch 本身并没有一个统一的数据绑定机制,MVVM 几乎是随着 RAC 这个 FRP 框架走近 iOS 开发者的视线的。利用 RAC 可以更优雅地实现数据绑定和 MVVM 模式。RxSwift 同样是个 FPR 框架,用它来实现 ViewModel 大概是这样的:

FRP 其实比较适合业务复杂型的项目,在我这个简单的例子中表现并不比方案三中普通的 ViewModel 更好。但是 RxSwift 是很好玩的,推荐大家就算正式项目中用不到,私下也可以自己玩玩儿~

1 1 收藏 评论

可能感兴趣的话题



直接登录
跳到底部
返回顶部