为何放弃MVC使用MVVM

Posted Cocoa开发者社区

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了为何放弃MVC使用MVVM相关的知识,希望对你有一定的参考价值。


MVC


全称是 Model View Controller,是模型 (model)-视图 (view)-控制器 (controller) 的缩写。它表示的是一种常见的客户端软件开发框架。


现在,MVC 已经成为主流的客户端编程框架,在 ios 开发中,系统为我们实现好了公共的视图类:UIView,和控制器类:UIViewController。大多数时候,我们都需要继承这些类来实现我们的程序逻辑,因此,我们几乎逃避不开 MVC 这种设计模式。


但是,几十年过去了,我们对于 MVC 这种设计模式真的用得好吗?其实不是的,MVC 这种分层方式虽然清楚,但是如果使用不当,很可能让大量代码都集中在 Controller 之中,让 MVC 模式变成了 Massive View Controller 模式。


Controller 的臃肿问题何解?


我们来看看 MVC 这种架构的特点。其实设计模式很多时候是为了Don't repeat yourself原则来做的,该原则要求能够复用的代码要尽量复用,来保证重用。在 MVC 这种设计模式中,我们发现 View 和 Model 都是符合这种原则的。


对于 View 来说,你如果抽象得好,那么一个 App 的动画效果可以很方便地移植到别的 App 上,而 Github 上也有很多 UI 控件,这些控件都是在 View 层做了很好的封装设计,使得它能够方便地开源给大家复用。


对于 Model 来说,它其实是用来存储业务的数据的,如果做得好,它也可以方便地复用。比如我当时在做有道云笔记 iPad 版的时候,我们就直接和 iOS 版复用了所有的 Model 层的代码。在创业做猿题库客户端时,iOS 和 iPad 版的 Model 层代码再次被复用上了。当然,因为和业务本身的数据意义相关,Model 层的复用大多数是在一个产品内部,不太可能像 View 层那样开源给社区。


说完 View 和 Model 了,那我们想想 Controller,Controller 有多少可以复用的?我们写完了一个 Controller 之后,可以很方便地复用它吗?结论是:非常难复用。在某些场景下,我们可能可以用addSubViewController之类的方式复用 Controller,但它的复用场景还是非常非常少的。


如果我们能够意识到 Controller 里面的代码不便于复用,我们就能知道什么代码应该写在 Controller 里面了,那就是那些不能复用的代码。在我看来,Controller 里面就只应该存放这些不能复用的代码,这些代码包括:


在初始化时,构造相应的 View 和 Model。


监听 Model 层的事件,将 Model 层的数据传递到 View 层。


监听 View 层的事件,并且将 View 层的事件转发到 Model 层。


如果 Controller 只有以上的这些代码,那么它的逻辑将非常简单,而且也会非常短。


但是,我们却很难做到这一点,因为还是有很多逻辑我们不知道写在哪里,于是就都写到了 Controller 中了,那我们接下来就看看其它逻辑应该写在哪里。


MVVM


Model-View-ViewModel 的简写。但在我的理解可以是Model-ViewModel-Controller-View


为什么要这样样理解呢?上面的问题Controller的代码处理太多东西,导致极其难复用,而且在后期调整业务,更换UI等事情上也会较为困难。


所以我的建议是将Controller的所有业务逻辑都应该移动到ViewModel层上。具体该做些什么呢?


我们可以将网络请求的借口,及返回的数据写在ViewModel里面,ViewModel再通知Controller来取得相应的数据,并显示在view上。


还可以将逻辑计算等方法封装在ViewModel里面,供Controller调用。当然如果这部分计算复用性很高,你还可以封装到其他公用的类里面。


而这个ViewModel将会是一个随时可以被其他功能模块调用的状态。而且,一个Controller可以使用一个或多个ViewModel。这样将会大大提高代码分复用性,及降低后期的维护。


MVVM 在使用当中,通常还会利用双向绑定技术,使得 Model 变化时,ViewModel 会自动更新,而 ViewModel 变化时,View 也会自动变化。而这个过程我们可以使用KVO和Notification来实现,但这样并不是最理想和高效的方式,所以我们需要结合ReactiveCocoa一起使用。


ReactiveCocoa是一个函数式编程(Functional Programming)和响应式编程(React Programming)库


函数式编程(Functional Programming),函数也变成一等公民了,可以拥有和对象同样的功能,例如当成参数传递,当作返回值等。看看 Swift 语言带来的众多函数式编程的特性,就你知道这多 Cool 了。


响应式编程(React Programming),原来我们基于事件(Event)的处理方式都弱了,现在是基于输入(在 ReactiveCocoa 里叫 Signal)的处理方式。输入还可以通过函数式编程进行各种 Combine 或 Filter,尽显各种灵活的处理。


无状态(Stateless),状态是函数的魔鬼,无状态使得函数能更好地测试。


不可修改(Immutable),数据都是不可修改的,使得软件逻辑简单,也可以更好地测试。


结合了RAC库,使得我们编写的程序更加简洁高效,维护性更高。


总结:


使用MVVM编写代码,虽然使层次增加了,但是提高了代码的复用性及提高了代码的可维护性,再结合RAC就更加牛B闪闪了。你们觉得呢?


以上是关于为何放弃MVC使用MVVM的主要内容,如果未能解决你的问题,请参考以下文章

携程为何放弃apollo

MVC / MVP / MVVM 到底是啥?

Android中MVC、MVP、MVVM的区别与使用

在 Windows Presentation Foundation 中使用 MVC 而不是 MVVM

MVC/MVVM模式特点及区别

MVC/MVVM模式特点及区别