浅谈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控件的多样化，处理起来比较复杂。