深入理解MVC和MVVM

知道91 | .Net | 2015-12-06 | 阅读:5282

MVC 的历史

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

  MVC 的概念最早出现在二十世纪八十年代的施乐帕克实验室中(对,就是那个发明图形用户界面和鼠标的实验室),当时施乐帕克为 Smalltalk 发明了这种软件设计模式。

csharp

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

  但是,几十年过去了,我们对于 MVC 这种设计模式真的用得好吗?其实不是的,MVC 这种分层方式虽然清楚,但是如果使用不当,很可能让大量代码都集中在 Controller 之中,让 MVC 模式变成了 Massive View 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,但它的复用场景还是非常非常少的。

MVVM 的历史

csharp

  MVVM 是 Model-View-ViewModel 的简写。

  相对于 MVC 的历史来说,MVVM 是一个相当新的架构,MVVM 最早于 2005 年被微软的 WPF 和 Silverlight 的架构师 John Gossman 提出,并且应用在微软的软件开发中。当时 MVC 已经被提出了 20 多年了,可见两者出现的年代差别有多大。

  MVVM 在使用当中,通常还会利用双向绑定技术,使得 Model 变化时,ViewModel 会自动更新,而 ViewModel 变化时,View 也会自动变化。所以,MVVM 模式有些时候又被称作:model-view-binder 模式。

  MVVM 的神化

  在使用中,我发现大家对于 MVVM 以及 MVVM 衍生出来的框架(比如 ReactiveCocoa)有一种「敬畏」感。这种「敬畏」感某种程度上就像对神一样,这主要表现在我没有听到大家对于 MVVM 的任何批评。

我感觉原因首先是 MVVM 并没有很大程度上普及,大家对于新技术一般都不熟,进而不敢妄加评论。另外,ReactiveCocoa 本身上手的复杂性,也让很多人感觉到这种技术很高深难懂,进而加重了大家对它的「敬畏」。

MVVM 的作用和问题

  MVVM 在实际使用中,确实能够使得 Model 层和 View 层解耦,但是如果你需要实现 MVVM 中的双向绑定的话,那么通常就需要引入更多复杂的框架来实现了。

  对此,MVVM 的作者 John Gossman 的 批评 应该是最为中肯的。John Gossman 对 MVVM 的批评主要有两点:

  第一点:数据绑定使得 Bug 很难被调试。你看到界面异常了,有可能是你 View 的代码有 Bug,也可能是 Model 的代码有问题。数据绑定使得一个位置的 Bug 被快速传递到别的位置,要定位原始出问题的地方就变得不那么容易了。

  第二点:对于过大的项目,数据绑定需要花费更多的内存。

  某种意义上来说,我认为就是数据绑定使得 MVVM 变得复杂和难用了。但是,这个缺点同时也被很多人认为是优点。

我们应该客观评价 MVVM 和 ReactiveCocoa

但是但是,我突然想到,我好象只需要一个 ViewModel 而已,我完全可以简单地做一个 ViewModel 的工厂类或 Service 类就可以了,为什么要引入这么多框架?现有的 MVC 真的有那么大的问题吗?

直到现在,ReactiveCocoa 在国内外还都是在小众领域,没有被大量接受成为主流的编程框架。不只是在 iOS 语言,在别的语言中,例如 Java 中的 RxJava 也同样没有成为主流。

  我在这里,不是想说 ReactiveCocoa 不好,也不是想说 MVVM 不好,而是想让大家都能够有一个客观的认识。ReactiveCocoa 和 MVVM 不应该被神化,它是一种新颖的编程框架,能够解决旧有编程框架的一些问题,但是也会带来一些新问题,仅此而已。如果不能使好的驾驭 ReactiveCocoa,同样会造成 Controller 代码过于复杂,代码逻辑不易维护的问题。

总结

我们需要保持的是一个拥抱变化的心,以及理性分析的态度。在新技术的面前,不盲从,也不守旧,一切的决策都应该建立在认真分析的基础上,这样才能应对技术的变化。