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 进行双向数据绑定、逻辑绑定等,这些先按下不表,下面举个例子分别说说这三种单向数据绑定的实现以及优缺点。

Profile.png

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

class ProfileHeader: UIView {

    @IBOutlet var contentView: UIView!
    @IBOutlet weak var backgroundView: UIImageView!
    @IBOutlet weak var avatarView: UIImageView!
    @IBOutlet weak var followersButton: UIButton!
    @IBOutlet weak var repositoriesButton: UIButton!
    @IBOutlet weak var followingButton: UIButton!
    @IBOutlet weak var nicknameLabel: UILabel!
    @IBOutlet weak var bioLabel: UILabel!

    // ...
}

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

方案一:View 作为 ViewModel

protocol ViewModelType {
    associatedtype Model
    func bind(model: Model)
}

extension ProfileHeader: ViewModelType {
    func bind(model: Profile) {
        let avatarURL = NSURL(string: model.avatar)
        backgroundView.presentImageAnimated(avatarURL)
        avatarView.presentImageAnimated(avatarURL)

        nicknameLabel.text = model.login

        bioLabel.text = model.bio ?? "Not set yet"

        let attributedFollowers = (title: "\(model.followers) \nFollowers", attributingTitle: "Followers")
        let attributedRepositories = (title: "\(model.repos) \nRepositories", attributingTitle: "Repositories")
        let attributedFollowing = ("\(model.following) \nFollowing", attributingTitle: "Following")
        followersButton.setAttributedTitle(attributedFollowers)
        repositoriesButton.setAttributedTitle(attributedRepositories)
        followingButton.setAttributedTitle(attributedFollowing)
    }
}

这个是我以前比较喜欢的做法,优点是简洁明了,没有太多弯弯绕绕的东西,基本就是把原本写在 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 为例:

typealias AttributedTitle = (title: String, attributingTitle: String)

private let attributingFollowers = "Followers"
private let attributingRepos = "Repositories"
private let attributingFollowing = "Following"

protocol RenderContext {
    func renderText(texts: String...)
    func renderAttributedText(attributedTexts: AttributedTitle...)
    func renderImage(imageURLs: NSURL...)
}

protocol ViewModelType {
    func renderInContext(context: RenderContext)
}

extension ProfileHeader: RenderContext {
    func renderText(texts: String...) {
        nicknameLabel.text = texts.first
        bioLabel.text = texts.last
    }

    func renderAttributedText(attributedTexts: AttributedTitle...) {
        followersButton.setAttributedTitle(attributedTexts[0])
        repositoriesButton.setAttributedTitle(attributedTexts[1])
        followingButton.setAttributedTitle(attributedTexts[2])
    }

    func renderImage(imageURLs: NSURL...) {
        backgroundView.presentImageAnimated(imageURLs.first)
        avatarView.presentImageAnimated(imageURLs.first)
    }
}

struct Profile {
    let login: String
    let id: Int
    let avatar: String
    let name: String
    let bio: String?
    let company: String?
    let blog: String
    let location: String
    let email: String?
    let repos: Int
    let followers: Int
    let following: Int
}

extension Profile: ViewModelType {
    func renderInContext(context: RenderContext) {
        context.renderText(login, bio ?? "Not set yet")

        let attributedFollowers = (title: "\(followers) \n\(attributingFollowers)", attributingTitle: attributingFollowers)
        let attributedRepositories = (title: "\(repos) \n\(attributingRepos)", attributingTitle: attributingRepos)
        let attributedFollowing = (title: "\(following) \n\(attributingFollowing)", attributingTitle: attributingFollowing)
        context.renderAttributedText(attributedFollowers, attributedRepositories, attributedFollowing)

        let avatarURL = NSURL(string: avatar) ?? defaultImageURL
        context.renderImage(avatarURL)
    }
}

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

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

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

protocol ViewModelType {
    var avatarURL: NSURL { get }
    var followers: AttributedTitle { get }
    var repositories: AttributedTitle { get }
    var following: AttributedTitle { get }
    var nickname: String { get }
    var bio: String { get }
}


struct ProfileHeaderViewModel: ViewModelType {

    // MARK: Output
    let avatarURL: NSURL
    let followers: AttributedTitle
    let repositories: AttributedTitle
    let following: AttributedTitle
    let nickname: String
    let bio: String

    init(input: Profile) {
        avatarURL = NSURL(string: input.avatar) ?? defaultImageURL

        nickname = input.login

        bio = input.bio ?? defailtProfileItem

        followers = (title: "\(input.followers) \n\(attributingFollowers)", attributingTitle: attributingFollowers)

        repositories = (title: "\(input.repos) \n\(attributingRepos)", attributingTitle: attributingRepos)

        following = (title: "\(input.following) \n\(attributingFollowing)", attributingTitle: attributingFollowing)
    }
}

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

var viewModel: ViewModelType! {
    didSet {
        nicknameLabel.text = viewModel.nickname

        configAvatar(viewModel.avatarURL)

        bioLabel.text = viewModel.bio

        configButtons(viewModel.followers, viewModel.repositories, viewModel.following)
    }
}

这样我们就可以声明多个 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 大概是这样的:

protocol ViewModelType {
    var avatarURL: Driver<NSURL> { get }
    var followers: Driver<AttributedTitle> { get }
    var repositories: Driver<AttributedTitle> { get }
    var following: Driver<AttributedTitle> { get }
    var nickname: Driver<String> { get }
    var bio: Driver<String> { get }
}

struct ProfileHeaderViewModel: ViewModelType {

    // MARK: Output
    let avatarURL: Driver<NSURL>
    let followers: Driver<AttributedTitle>
    let repositories: Driver<AttributedTitle>
    let following: Driver<AttributedTitle>
    let nickname: Driver<String>
    let bio: Driver<String>

    init(input: Profile) {
        let profileDriver = Driver.of(input)
        avatarURL = profileDriver
            .map { $0.avatar }
            .map { NSURL(string: $0) ?? defaultImageURL }

        followers = profileDriver
            .map { (title: "\($0.followers) \n\(attributingFollowers)", attributingTitle: attributingFollowers) }

        repositories = profileDriver
            .map { (title: "\($0.repos) \n\(attributingRepos)", attributingTitle: attributingRepos) }

        following = profileDriver
            .map { (title: "\($0.following) \n\(attributingFollowing)", attributingTitle: attributingFollowing) }

        nickname = profileDriver
            .map { $0.login }

        bio = profileDriver
            .map { $0.bio ?? defailtProfileItem }
    }
}

class ProfileHeader: UIView {
    // ...

    private let bag = DisposeBag()
    var viewModel: ViewModelType! {
        didSet {
            viewModel.nickname
                .drive(nicknameLabel.rx_text)
                .addDisposableTo(bag)

            viewModel.avatarURL
                .drive(onNext: configAvatar)
                .addDisposableTo(bag)

            viewModel.bio
                .drive(bioLabel.rx_text)
                .addDisposableTo(bag)

            Driver.zip(viewModel.followers, viewModel.repositories, viewModel.following) { ($0.0, $0.1, $0.2) }
                .drive(onNext: configButtons)
                .addDisposableTo(bag)
        }
    }

    // ...
}

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

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Java后端技术栈

【面试题】2018年最全Java面试通关秘籍第三套!

注:本文是从众多面试者的面试经验中整理而来,其中不少是本人出的一些题目,网络资源众多,如有雷同,纯属巧合!禁止一切形式的碰瓷行为!未经允许禁止一切形式的转载和复...

1291
来自专栏GopherCoder

『No19: Gorm 上手指南』

如果你是做后端开发的,日常工作中,除了熟悉编程语言之外,数据库怕是最常用的技术了吧。

6811
来自专栏Coding01

深入浅出 Laravel Echo (3)

看完 public channel 的流程,我们该来说说怎么跑通 private channel 了。

2633
来自专栏猿湿Xoong

Android SystemUI(二):启动流程和初始化

2874
来自专栏算法修养

HttpClient参观记:.net core 2.2 对HttpClient到底做了什么?

.net core 于 10月17日发布了 ASP.NET Core 2.2.0 -preview3,在这个版本中,我看到了一个很让我惊喜的新特性:HTTP C...

1691
来自专栏何俊林

Android插件实战总结之TwsPluginFramework

图:浙江乌镇 小编导读:本文是基于rickdynasty(TwsPluginFramework 作者陈上勇)的github上关于TwsPluginFramewo...

2528
来自专栏佳爷的后花媛

Android面试问题整理

      作为一个即将毕业的Android程序媛,开始面临找工作了,本媛媛还是有点小紧张,于是收集了一些Android面试的题目.希望能够用上.如果大家有A...

2002
来自专栏Linyb极客之路

并发编程之Semaphore

一、简介 Semaphore(信号量)是用来控制同时访问特定资源的线程数量,它通过协调各个线程,以保证合理的使用公共资源。很多年以来,我都觉得从字面上很难理解...

4218
来自专栏有趣的Python和你

Python数据分析之贴吧的问与答读取数据库获取question列分词词云

1253
来自专栏王清培的专栏

.NET/ASP.NETMVC 大型站点架构设计—迁移Model元数据设置项(自定义元数据提供程序)

阅读目录: 1.需求背景介绍(Model元数据设置项应该与View绑定而非ViewModel) 1.1.确定问题域范围(可以使用DSL管理问题域前提是锁定领域...

2185

扫码关注云+社区

领取腾讯云代金券