关于MVC、MVP、MVVM架构模式的区别

      大家好，我是阿桃，一个想成为被点赞关注的程序员。

     工控行业、物联网行业、机器人行业软件开发可联系我

1.什么是MVC、MVP、 MVVM架构模式

    MVC是一种架构模式，MVP与MVVM是MVC的一种变形，这两种架构模式都将View与Model完全解耦，前者将太多的Model操作放入到Controler中后者则是将Model与Control合并，结构模式的选择只有合适与不合适没有好坏之分。(应该根据实际场景选择使用的架构模式，目前自己不具备选择适当架构模式的能力)

MVC：

MVC－－－－－Model－View-Controller

MVVM –>M：Model 模型

V: View 视图

C: Controller 控制器

    Model层。也叫模型层，主要负责和数据交互的任务。模型层主要功能有定义数据结构。从数据库读、取数据，数据格式验证，读数据进行加工处理。

    Model层类似与三层架构中的DAL 层。主要与数据库进行交互。而且进行简单的数据处理。

    View层，即视图层，负责全部界面层的任务。事实上就是写入数据和显示数据。主要功能有获得数据，显示数据。决定界面技术（HTML，XML，Flash等）。界面排版；向Controller返回数据，决定数据传送方式，数据验证。

    View层类似于三层中的UI层，主要是和用户进行数据交互的。

    Controller层。集控制层。接受用户输入的数据。调用模型和视图完毕用户的需求。当用户单击超链接或者发送HTML表单时。控制器事实上不做不论什么的处理和输出，它仅仅是依据实际情况决定调用哪个模型或者视图去处理这个请求，然后决定使用哪个视图来显示返回的处理结果。

    经典MVC模式中对于Model和Controller的定义则较为模糊，以致在项目实践中对它们的职责产生了很多不同的理解。其中比较主流的有下面两种。

1、闭环党

    比较传统，问题是Model和Controller职责不清，在实操时容易走形

2、开放派

    MVP的前身，问题是Controller职责太重，优点是View和Model没有了直接的关联

MVP：

    如果我们希望View和Model脱离关联的话，那么很容易就会使得所有的职能都落到Controller头上，就如同上图所示。这样，Controller也就变成了Presenter，MVC也正式演化为MVP。所有的数据都由Presenter来驱动，所有的业务逻辑也由Presenter来实现。

    MVP模式常见于Android，是谷歌官方推荐的App设计模式。从我找到的这张图上，可以非常明显地看出三者之间的关系。

    Model只是一个数据通道，退化成了Repository。如果将Model扩而大之，那么就会变成下面这张图描述的场景：

    Model摇身一变，成了一个数据交换中心。

    MVP模式的优点是实现了View和Model的解耦，缺点是Presenter职责太重。

MVVM：

    MVVM模式现在非常流行，下面这张图描述了MVVM模式各部分的关系和职能：

    MVVM模式同样实现了View和Model的解耦。不过和MVP模式不同的是，MVVM是从数据驱动的角度出发来解决这个问题的。ViewModel和View实现双向数据绑定，ViewModel的数据变化自动地反应到View上。这样，ViewModel就代表了View，成了一个Agent。ViewModel也承担一点业务逻辑，但非常有限（也有把大量业务逻辑放在ViewModel里面的做法，这个就和MVP没什么本质区别了）。所以，业务逻辑的职能就只能由Model来扛了。事实上，MVVM模式本质上是MVC模式去掉了Controller或者说是Model合并了Controller。

    MVVM模式的优点是双向数据绑定带来的便利，Model完全不需要关心View。以数据为核心的视角非常新颖，并且在处理业务逻辑上也更加直观。缺点其实和MVP一样，只不过它是Model臃肿而已。

2.为什么要使用MVC设计模

    第一: 一种比较常用的设计模式，能够做到各层专注于各自的功能，易于扩展、管理等。

    第二:  MVC使前后台相互分离，双方通过控制器来进行控制，且相互之间不影响。这样在编程的时候，前台可以安心做前台，后台可以专注于功能。且修改的时候非常容易。

    第三：应对需求不断的变化，程序猿对于产品狗的敌意就来自于不断地更改需求。于是，少改、好改就成了程序员的永恒目标。行之有效的套路其实也就是分层解耦而已。无论是Model/Controller还是Model/Presenter或者Model/ViewModel，不过是分层的角度和方法不同而已。

3.MVC设计模存在的问题

    1、增加了系统结构和实现的复杂性。对于简单的界面，严格遵循MVC，使模型、视图与控制器分离，会增加结构的复杂性，并可能产生过多的更新操作，降低运行效率。

    2、视图与控制器间的过于紧密的连接。视图与控制器是相互分离，但确实联系紧密的部件，视图没有控制器的存在，其应用是很有限的，反之亦然，这样就妨碍了他们的独立重用。

    3、视图对模型数据的低效率访问。依据模型操作接口的不同，视图可能需要多次调用才能获得足够的显示数据。对未变化数据的不必要的频繁访问，也将损害操作性能。

    4、耦合性度比较高,目前，一般高级的界面工具或构造器不支持模式。改造这些工具以适应MVC需要和建立分离的部件的代价是很高的，从而造成MVC使用的困难。

4.MVC架构模式的改进

    目前无法确认别人的改进是否有问题，后续需要研究，这个还是需要更具特定场景进行特定分析。

文章每周持续更新，原创虽短，确不容易，欢迎大家点赞关注，一起交流技术一起提升成长。