MVC、MVP、MVVM模式的区别

    很多你以为非常新潮的概念，或许仅仅是被人们重新赋予了新的名字，当你理清这一切的来龙去脉以后，你会发现这一切并没有什么不同。

    我个人更喜欢通过将MVC、MVP和MVVM这三者横向对比的方式来加强理解，因为这从某种意义上来讲，这是一个逐步改进和演化的过程。我们常常谈及软件的三层架构，我们常常对MVC耳濡目染以致将其神化，可事实上它们是某种在思想上无限接近的理念而已。

  首先，我们从最简单的MVC开始说起，作为最常用的软件架构之一，我们可以从上面的图示中看到，MVC其实是非常简单的一个概念，它由模型(Model)、视图(View)和控制器(Controller)三部分组成，建立在一个单向流动的通信基础上，即View通知Controller响应用户请求，Controller在接到View的通知后会更新Model内的数据，然后Model会将新的数据反馈给View。我们发现这个设计可以使软件工程中的关注点分离，我们注意到通过MVC模式，我们实现了视图和模型的分离，通过控制器这个胶水层让两者间接联系起来，所以MVC的优点是让各个模块更好的协作。那么，它的缺点是什么呢？显然，视图和控制器是高度耦合的，因为控制器中无可避免地要访问视图内的元素，所以控制器注定无法在这尘世间独善其身。要知道最早的MVC架构是基于观察者模式实现的，即当Model发生变化时会同时通知View和Controller，所以我们很快就可以认识到：我们从古至今的所有努力，都是为了让视图和模型彼此分离，我们在这条路上越走越远，幸运的是一直都不忘初心。

  接下来，我们为了彻底地让视图和模型分离，我们发明了新的软件架构：MVP。虽然从感性的认识上来讲，它是将Controller改名为Presenter，然而从理性的认识上来讲，它在让视图和模型分离这件事情上做得更为决绝果断。通过图示我们可以发现，视图和模型不再发生直接联系，它们都通过Presenter相互联系，而且各个部分间的通信都变成了双向流动。我们可以很快意识到，现在全新的控制器即Presenter会变得越来越“重”，因为所有的逻辑都在这里，而视图会变得越来越“轻”，它不再需要主动去获取模型提供的数据，它将被动地接拥抱变化，因为现在在视图里基本上没有任何业务逻辑。现在我们可以预见，人类会在隔绝视图和模型这件事情上乘胜追击，人们会尝试让Controller/Presenter/ViewModel变得越来越臃肿，我想说的是，求它们在得知这一切真相时的心理阴影面积，我们试图让每一个模块各司其职、通力协作，结果脏活累活儿都交给了Controller/Presenter/ViewModel，我想说这件事情做的真是漂亮。

  历史总是如此的相似，人类在作死的道路上匍匐前进，继续发扬改名的优良传统，这一次是Presenter被改名为ViewModel，在命名这件事情上，我认为程序员都是有某种强迫症因素在里面的，所以当你发现一个事物以一个新的名字出现在你的视野中的时候，通常它会有两种不同的结局，第一，陈酒换新瓶，我们贩卖的不是酒是情怀；第二，看今天的你我怎样重复昨天的故事，我这张旧船票还能否登上你的客船。幸运的是，MVVM相对MVP的确发生了些许改变，一个重要的特性是双向绑定，View的变化将自动反映在ViewModel中，而显然ViewModel是一个为View打造的Model，它可以容纳更多的普通的Model，因此从某种意义上来说，ViewModel依然作为连接View和Model的桥梁而出现，它是对View的一种抽象，而抽象有两层含义，即数据(Property)和行为(Command)，一旦你明白了这一点，ViewModel无非是一个特殊而普通的类而已，特殊是因为它需要实现INotifyPropertyChanged接口，普通是因为它继承了面向对象编程(OOP)的基本思想。