MVC、MVVM、MVP都是常见的设计模式和常见的设计思想，那么它们之间有什么区别呢？接下来，他们简单总结一下三种模式的介绍1.MVC：经典设计模式MVC全称ModelViewController，是Model（模型）-View（视图）-Controller（控制器）的缩写。他在1970年代被介绍给软件设计界的公众。MVC模式致力于关注点分离，这意味着模型和控制器的逻辑不链接到用户界面（View）。因此，维护和测试程序变得更加简单和容易。Model层：model（用于封装业务逻辑相关数据，操作数据）View层：view（渲染图形界面，又称UI界面）Controller层：controller（M和V之间的连接器，主要处理业务逻辑，包括显示数据、界面跳转、管理页面生命周期等）标准MVC工作模式：当用户的行为触发操作时，控制器（Controller）更新模型并通知视图（V）和模型（M）更新，然后视图（V）会向模型（M）请求新的数据，这是标准MVC模式下Model、View、Controller之间的协作方式。MVC的优点：耦合度低，视图层和业务层分离，允许更改视图层代码而不需要重新编译模型和控制器代码；高复用性；低生命周期成本；MVC使得开发和维护用户界面的技术含量减少；可维护性高，视图层和业务逻辑层的分离也使得WEB应用更容易维护和修改；快速部署。MVC缺点：不适合中小型应用程序，花大量时间将MVC应用到不是很大的应用程序通常是得不偿失的。视图和控制器连接得太紧。视图和控制器彼此分离，但它们是密切相关的组件。view没有controller，它的应用范围很有限，反之亦然，这就阻碍了它们的独立性。重用。视图对模型数据的低效访问，根据模型操作接口的不同，视图可能需要多次调用才能获取足够的展示数据。不必要地频繁访问未更改的数据也会损害操作性能。2.MVP：MVP模式将Controller的名称改为Presenter，同时改变通信方向。MVP的全称是ModelViewPresenter，由MVC演变而来。它和MVC的相同点在于：Controller/Presente负责业务逻辑，Model管理数据，View负责展示。然而，在MVP中，View并不直接与Model交互。它们之间的通信是通过Presenter（MVC中的Controller）进行的，即Presenter是用来解耦View和Model的，使它们之间没有任何关系。众所周知，通信是通过Presenter进行的。Model层：model（用于封装业务逻辑相关数据和操作数据）View层：view（渲染图形界面，又称UI界面）Presenter层：controller（M和V之间的连接器，主要处理业务逻辑，包括展示数据、界面跳转、管理页面生命周期等）标准MVP工作模式：在MVP中，Presenter可以理解为一个松散的控制器，里面包含了view的UI业务逻辑，所有从view发出的事件都会被处理由演示者通过代理；同时Presenter也通过view暴露的接口与之通信。MVP特点：M、V、P双向通信，View和Model不通信，通过Presenter传递。Presenter将Model和View完全分离，主要的程序逻辑都在Presenter中实现。View非常瘦，不部署任何业务逻辑。叫做“被动视图”（PassiveView），也就是没有主动性，而Presenter很厚，所有的逻辑都部署在那里。Presenter与具体的View没有直接关系，而是通过定义的接口进行交互，这样当View发生变化时Presenter可以保持不变，从而实现复用。不仅如此，你还可以编写一个测试用的View来模拟用户的各种操作，从而实现对Presenter的测试——这样就不需要使用自动化测试工具了。MVP的优点：模型和视图完全分离，我们可以在不影响模型的情况下修改视图；该模型可以更有效地使用，因为所有交互都发生在一个地方-在Presenter内；我们可以对多个视图使用一个Presenter，不需要改变Presenter的逻辑。这个特性非常有用，因为视图总是比模型更改得更频繁；如果我们将逻辑放在Presenter中，那么我们可以在没有用户界面的情况下测试这些逻辑（单元测试）。MVP的缺点：View和Presenter的交互会过于频繁，导致他们的联系过于紧密。换句话说，一旦View改变，Presenter也跟着改变。3、MVVMMMVVM的全称是ModelViewViewModel。此模式提供视图和视图模型之间的双向数据绑定。这使得视图模型中的状态更改能够自动传播到视图。通常，ViewModel通过观察者模式（observerpattern）通知ModelViewModel的变化。模型层：模型层表示描述业务逻辑和数据的一系列类的集合。它还定义了数据修改和操作的业务规则。View层：View代表UI组件，如CSS、JQuery、html等，他只负责展示从Presenter接收到的数据。也就是将模型转化为UI。ViewModel层：ViewModel负责暴露方法、命令和其他属性来操作View的状态，将模型组装成View动作的结果，并触发View本身的事件。MVVM模式的关键点：用户和View的交互。View和ViewModel是多对一的关系。这意味着一个ViewModel只映射多个视图。View持有对ViewModel的引用，但ViewModel没有关于View的任何信息。View和ViewModel之间存在双向数据绑定关系。MVVM优点：耦合度低，View（视图）可以独立于Model改变和??修改，一个ViewModel可以绑定不同的“Views”，当View改变时，Model可以保持不变，当Model改变时，View可以不变。复用性，可以把一些视图逻辑放在一个ViewModel中，这样很多视图都可以复用这个视图逻辑。独立开发，开发人员可以专注于业务逻辑和数据开发（ViewModel），设计师可以专注于页面设计，使用ExpressionBlend可以轻松设计界面和生成xml代码。Testable，接口一直很难测试，现在可以针对ViewModel来写测试了。三种模式的区别MVC是世界上最低级、最原始的UI模式；MVC就是把M绑定到V上，然后C负责处理整个界面的提交请求，一遍又一遍的刷新整个V。这个机制。所以MVC的标志就是“初级，单向绑定，一遍遍刷新UI”。MVP深入程序的“骨髓”。UI设计模板绑定了MVP事件定义，允许程序员捕获此类组件的丰富事件，然后在事件处理过程中直接从控件树中访问所有其他组件。控件，直接修改其属性。开发的精力主要花在学习各种控件的内部机制上，学习曲线陡峭。所以MVP的标志是“复杂的、事件驱动的、精细到每一个控制层级”。MVVM是对MVP的改进。它隔离了控制操作层。UI模板上的各种控件直接绑定到VM层的属性上，这样当VM属性改变时，UI控件会自动更新，反之亦然。更新虚拟机属性。这种编程方式不是要处理大量的控件事件，而是编写少量的VM属性变化行为代码。大部分开发精力都放在了业务和UI的绑定上，没必要去研究控件的内部机制。三种设计模式的应用1.MVC模式。React使用MVC模式。所有MVC框架都是单向数据流。特点：使用VirtualDOM提供Reactive和Composable视图组件。将注意力集中在核心库上，将路由和全局状态管理等其他功能留给相关库。注意：react其实是一个“伪MVC”。其实就是MVP，但是深知MVP模型的弊端。明明是基于组件，绑定组件变化事件，却有办法使用虚拟DOM来一遍又一遍的刷新UI控件（而且为了解决性能问题，还有各种负责任的怪异的反模式操作避免全局刷新UI树）。所以虽然React称自己为MVC模式，但它实际上是MVP的变体。2.MVP模式。JQuery是非常经典的MVP编程模式3.MVVM模式。Knockout、AngularJS、Vue等都可以看作是Angular使用的MVVM模式。当触发UI事件、ajax请求或超时延迟时，会触发脏检查。这时会调用$digest循环遍历listener中的所有数据，判断当前值是否与之前的值不同。如果检测到变化，将调用$watch函数，最后更新所有变化，并调用apply()。将新数据呈现到页面的方法。优点：一次检测会收集所有的数据变化，然后统一更新UI，大大减少了对DOM的操作次数。缺点：只要有ui或者ajax或者settimeout的操作就会被检查，watcher之间交互的时候会触发多次$digest循环，这样如果watcher太多的话会非常影响性能.注意：AngularJS在MVVM上做的不是很好，趋向于MVP。只有Knockout实现了经典的MVVM设计模式，并且有几个与性能相关的特性（例如自动延迟UI刷新，自动稀化无用的UI刷新操作）可以提高性能（与许多其他Web前端框架相比）在至少几十次。从某种意义上说，Vue是React和Angular的集大成者。它吸收了MVVM的数据管理思想，同时应用了React的虚拟Dom算法。它使用双向数据绑定来满足开发的方便，但在不同组件之间也使用单向数据流来保证数据的可控性。它使用了大量的Angular指令语法，但是创新了Angular的脏数据检查机制，利用数据劫持来违反合法的数据检查机制。它借鉴了React的组件化思想，大大增加了前端工程的结构标准化。注意：Vue内部使用Object.defineProperty()实现双向绑定，通过它可以监听set和get事件。总结一下，MVC就是把控件绑定到M上，一遍又一遍的刷新UI。另一方面，MVP将控件单向绑定到事件。它的假设是程序员喜欢编写低级代码来操作控件。另一方面，MVVM在两个方向上将控件绑定到VM。它的假设是，在设计交互界面时，最喜欢编写高级语句来操纵用户业务行为的变化。
