MVP前奏（二）MVC在Android的小短腿

首先，这是我的一家之辞，做个参考就好。

这个作为MVP的前篇，就是说一下MVC在Android中的不足之处。

在Android中，M这个好说，它是面向对象的产物，它就是抽象出来对象，程序员在程序里可以有很多对象（是对象，不是女朋友！），在说白了就是个表示数据结构的类。在MVP和MVC中几乎没差别。

V这个模块，因为Android代码的特性，activity作为活动会表现在最上层，它可以被看作是V的，但是大家的逻辑代码通常也在activity中，这里来看，它又是属于C的；就“activity”这个词来说，我更倾向它是属于V的。自定义的View都是属于V的这个没啥大的争议。事实上activity中VC处于比较严重的交叉状态。

C作为控制器，在Android中有时候可以到处看到，简单的说个adapter，这个玩意是绑定数据用的，属于C的范围。Adapter当然可以独立的写在一个类中，但是当你有些晦涩的数据的时候，还是在activity中来个内部类简单。VC又混在了一起。当你在adapter中使用Viewholder，又是V的范畴。其他的一些属于C的东西，也常会放置在activity中。

来一张自己画的丑到难受的图：

从这样看，activity的特殊性，也就是它几乎VC都有的情况，带了一个问题，不容易解耦，当M有点小变化，你可能要改activity，当C有变化，又可能改activity，V有变化，还是要改activity......

传统的MVC这一套在Android上，存在解耦方面的不足表现。于是需要新的优化的东西来处理一下或者说弥补一下这个不足。

到这里里提一下Android上目前流行的有两个框架：MVP和MV’VM’。’VM’引起来是说它们是一个东西，而不是两个，因为我最初看到时我就误解了。

MVP和MVVM只是MVC的变种。本质还是MVC。