MVC、MVVM架构模式

今天和大家谈谈我所理解的MVC,以及现在比较流行的MVVM。首先我们应该明白,计算机实现一个功能核心代码就那么点。这里面最主要的目的就是为了维护和可扩展。在设计模式里面,如果你能遵循单一原则,你的代码就已经很好了。

MVC

做iOS开发,一直教导一定要遵循MVC模式开发。千遍一律的讲,无非M是数据模型V是视图C是控制器。而在我们iOS中,controller可不仅仅只是处理数据了,还负责view的管理以及事件的传递。MVC本质就是将数据展示和数据进行隔离,提高代码的复用性和扩展性。

看看斯坦福老爷爷的一张图:

123

这就是我们所认识的MVC。我们可以看到,Controller可以Model通信,也可以和View进行通信。继续看Controller和Model的关系,绿色的箭头代表Controller也可以直接进行对Model的访问,也就是说Model对于Controller来说就是透明的。但是Model并不知道Controller是谁。如果Model发生了变化,那么就通过Notification和KVO的方式传递给Controller。同样的Controller和View之间也是这种关系,View对Controller来说就是 透明的。Controller可以直接根据Model决定View的展示。View如果接受响应事件则通过delegate,target-action,block等方式告诉Controller的状态变化。Controller进行业务的处理,然后再控制View的展示。

到这里你会发现Model和View并不能直接的进行通信,都必须通过Controller。那这样Model和View就是相互独立的。View只负责页面的展示,Model只是数据的存储,那么也就达到了解耦和重用的目的。

controller本来就是用来处理业务的。有点开发经验的都知道,如果业务复杂起来,再加上其他乱七八糟的验证,controller就会变得很大,越来越难以维护。这个也是MVC比较明显的缺点。

MVVM

既然controller越来越臃肿,越来越难以维护,我们怎么去优化和瘦身呢?回头再仔细看看我们所谓的业务逻辑,是干什么的?无非就是根据几个数据得出一个数据用来控制view的显示。比如展示的是什么文案,按钮能不能响应,页面能不能跳转等等。那MVVM就干了这件事,帮忙分担一下controller里面的部分业务逻辑。MVVM更合理的应该叫做MV-CM。

123

这个时候,controller将不再直接和真实的model进行绑定了,而通过ViewModel,viewModel进行持有真实的Model。

一切都和viewModel进行交流。如果有其他响应事件,是需要viewModel开放方法来进行处理的,并要通知VC处理结果的。

关于MVVM的优点

$ 方便测试

在MVC下,Controller基本是无法测试的,里面混杂了个各种逻辑,而且分散在不同的地方。有了MVVM我们就可以测试里面的viewModel,来验证我们的处理结果对不对(Xcode7的测试已经越来越完善了)。

$ 便于代码的移植

比如iOS里面有iPhone版本和iPad版本,除了交互展示不一样外,业务逻辑的model是一致的。这样,我们就可以以很小的代价去开发另一个app。(以前做公司iPad的时候就深深感觉到,全部在VC里面是多么的痛苦和重新开发一个没有啥区别)。

$ 兼容MVC

MVVM是MVC的一个升级版,目前的MVC也可以很快的转换到MVVM这个模式。VC可以省去一大部分展示逻辑。

缺点

$ 类会增多

每个VC都附带一个viewModel,类的数量*2

$ viewModel会越来越庞大

我们把逻辑给了viewModel,那势必Model也会变得很复杂,里面的属性和方法越来越多。可能重写的方法比较多,因为涉及到一些数据的转换以及和controller之间的通信。

$ 调用复杂度增加

由于数据都是从viewModel来,想想突然来了一个新人,一看代码,不知道真实的模型是谁。比如常用tableview的数据源,一般都是一个数组,如果不断的通过viewModel去取,沟通上没有那么直接。况且每封一层,意味着要写很多代码去融合他们的转换。