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 是很好玩的,推荐大家就算正式项目中用不到,私下也可以自己玩玩儿~

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 151,829评论 1 331
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 64,603评论 1 273
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 101,846评论 0 226
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 42,600评论 0 191
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 50,780评论 3 272
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 39,695评论 1 192
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,136评论 2 293
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 29,862评论 0 182
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 33,453评论 0 229
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 29,942评论 2 233
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,347评论 1 242
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 27,790评论 2 236
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,293评论 3 221
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 25,839评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,448评论 0 181
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 34,564评论 2 249
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 34,623评论 2 249

推荐阅读更多精彩内容