浅谈MVC、MVP、MVVM模式

mvc的模式已经深入人心，想必大家都很熟悉，但是未必都能遵守mvc模式。我们的一个mvc项目比较简单，主要是数据库的查询。一个DBHelp类，封装了数据库的操作，然后Controller中进行中各种查询，包含分页查询。也就是说，所有的逻辑全部在Controller中完成。请问这还是mvc模式吗？

严格意义上，已经违背了mvc模式，但是从实践层面看，似乎没有什么问题，这样做简单好多。我们知道mvc把一个应用程序划分了三个层次结构。Model、View和Controller，Model代表了业务逻辑，比如说数据库的各种查询，Controller就是调用Model中的方法，然后把Model中的数据部分填充，最后选择View，把Model数据给View。

我们的Model文件夹下存放的是自定义的ViewModel，ViewModel作为view的数据源对象。这时候，我们是不是可以称为MVVMC模式呢？我们去掉C，加上数据绑定，这不就是MVVM模式吗？我觉得MVVM模式的亮点在于数据绑定，也就是View和ViewModel的绑定。有一个js叫knockout.js是一个前台的MVVM框架。WPF，也是典型的MVVM模式。

我觉得mvc模式，适合界面和逻辑都比较复杂的项目。比如我们用的webform，有些人会在页面的CodeBehind中，写入大量的代码，少则几千，多则上万。界面的逻辑与功能的逻辑的代码彻底耦合在一起。维护起来的确不容易。针对如此情况，我们用mvc是不是能好一些?无论哪一种模式，都是分层的思想，没有人能用一个方法把所有的逻辑都包含在里面。MVC、MVP、MVVM模式，它们旨在分离View和Model，避免过度耦合。MVP模式，分离的更彻底。它通过引入IView接口，在View中实现IView接口。View中可以直接调用P，而P中注入了IView，因此P可以间接地调用View，P中可以调用M，M封装了业务逻辑。这样View和Model彻底分离。这个模式好不好？就看从哪个角度说了。如果项目中，对测试要求很高的话，这个模式确实好。View和Model可以单独测试。但是这个模式实现起来有些麻烦。因此，对某些测试要求高的View和Model使用此模式应该更好一些。

MVVM模式，可以实现对Model的实时变化的监控。以及自动化测试可以基于此模式。

MVC：从View开始，用户在View上的任何操作，都可以调用Controller，Controller调用Model，然后更新View。

MVP：View和Model完全解耦

MVVM：View和Model也没有直接的关系，它和MVP有点相似。

这三个模式本质上都反映了Model和View之间的关系。传统的MVC和MVP都是Model变化，然后更新View，但是MVVM更进一步，它的View变化，导致ViewModel直接变化。这样最大的优点，就是省略了从View到ViewModel的映射。我们可以直接”忘记”View，只需要Model和ViewModel交互。毕竟View比较麻烦，它的UI控件，也就是Html控件的多样化，处理起来比较复杂。