如果我们使用短语“MVC, MVP和MVVM设计模式之间的差异”搜索谷歌,那么我们可能会得到一些讨论MVC MVP和MVVM设计模式理论上的差异的URL,例如:

MVP

在无法通过“dataContext”进行绑定的情况下使用。 Windows窗体就是一个很好的例子。为了将视图与模型分开,需要一个表示器。由于视图不能直接绑定到演示者,信息必须通过接口(IView)传递到视图。

MVVM

在可能通过“dataContext”进行绑定的情况下使用。为什么?每个视图的各种IView接口被删除,这意味着需要维护的代码更少。 一些例子中,MVVM是可能包括WPF和javascript项目使用Knockout。

MVC

在视图和程序其余部分之间的连接并不总是可用的情况下使用(并且您不能有效地使用MVVM或MVP)。 这清楚地描述了web API与发送到客户端浏览器的数据分离的情况。微软的ASP。NET MVC是管理这种情况的一个很好的工具,并提供了一个非常清晰的MVC框架


但我还没有找到一篇文章从理论上讨论了这种差异,并附带了示例代码。

如果我能得到一篇文章,讨论这3种设计模式(MVC, MVP和MVVM)之间的区别以及代码,那就太好了。

我想要得到3个类似的CRUD应用程序的源代码,它们已经由这三种设计模式(MVC, MVP和MVVM)实现。这样我就可以通读代码,了解如何为这三种设计模式(MVC, MVP和MVVM)编写代码。

因此,如果有任何这样的文章讨论了这3种设计模式(MVC, MVP和MVVM)的代码如何不同,那么请将我转到那篇文章。


当前回答

MVC vs MVP vs MVVM

模型视图控制器

View(.xml, .storyboard) - Controller(Activity, Controller) - Model(Others)

视图-渲染UI 控制器与视图绑定

MVP -模型视图演示器

View(.xml, .storyboard, Activity, Controller) - Presenter(plain Class) - Model(Others)

百达

View(.xml with data, view.swift) - ModelView(ViewModel, ObservableObject) - Model(Others)

Android DataBinding, SwiftUI

MVVM采用数据绑定或双向数据绑定的方式,在观察的基础上连接View和ModelView

有时在UI世界(iOS, Android),你可以找到额外的对象(路由器,导航器,协调器),负责导航和设置依赖项

其他回答

一些基本的区别可以简单地写下来:

MVC:

传统的MVC是有一个

模型:作为数据的模型 视图:处理用户的视图,可以是UI 控制器:控制模型和视图之间的交互,视图调用控制器来更新模型。如果需要,视图可以调用多个控制器。

MVP:

与传统的MVC类似,但控制器被演示器取代。但与控制器不同,演示者也负责改变视图。视图通常不调用演示者。

MVVM

不同之处在于视图模型的存在。它是观察者设计模式(Observer Design Pattern)的一种实现,其中模型中的更改也通过VM在视图中表示。 例:如果一个滑块被改变,不仅模型被更新,而且显示在视图中的文本数据也会被更新。因此有一个双向数据绑定。

来自http://geekswithblogs.net/dlussier/archive/2009/11/21/136454.aspx的精彩解释

让我们先看看MVC

输入首先指向控制器,而不是视图。这些输入可能来自与页面交互的用户,但也可能来自简单地在浏览器中输入特定的url。在任何一种情况下,它都是一个用于启动某些功能的控制器。

控制器和视图之间存在多对一关系。这是因为单个控制器可能会根据正在执行的操作选择要呈现的不同视图。

从控制器到视图有一个方向箭头。这是因为视图没有任何控制器的知识或引用。

控制器传递回模型,所以视图和预期模型之间有知识被传递给它,而不是控制器提供它。

MVP -模型视图演示器

现在让我们看看MVP模式。它看起来非常类似于MVC,除了一些关键的区别:

输入从View开始,而不是Presenter。

视图和相关的演示者之间存在一对一的映射。

视图持有对演示者的引用。Presenter也会对视图触发的事件做出反应,因此它知道与之关联的视图。

演示者根据它在模型上执行的请求操作更新视图,但视图不是模型感知的。

模型视图视图模型

所以,MVC和MVP模式摆在我们面前,让我们来看看MVVM模式,看看它有什么不同:

输入开始于视图,而不是视图模型。

虽然视图持有对视图模型的引用,但视图模型没有关于视图的信息。这就是为什么在不同的视图和一个视图模型之间可以有一对多的映射,甚至跨技术。例如,WPF视图和Silverlight视图可以共享同一个视图模型。

mvc, MVP, MVVM

MVC(旧的)

MVP(更模块化,因为它的低耦合。表示者是视图和模型之间的中介)

MVVM(在VM和UI组件之间已经有了双向绑定,因此它比MVP更自动化)

下图来自Erwin van der Valk的文章:

本文解释了这些区别,并给出了c#中的一些代码示例

MVP:

优点:

演示者将出现在模型和视图之间。Presenter将从Model中获取数据,并根据视图的需要对数据进行操作,并将其交给视图,视图只负责渲染。

缺点:

1)我们不能对多个模块使用presenter,因为数据在presenter中被一个视图类修改。

3)打破Clean架构,因为数据流应该只向外,但这里数据是从演示者返回到视图。

MVC:

优势:

这里我们在视图和模型之间有控制器。这里的数据请求将从控制器到视图完成,但数据将以接口的形式发送回视图,而不是与控制器。控制器不会因为很多事务而膨胀。

不服光彩:

数据操作应该由视图来完成,这将是UI线程上的额外工作,如果数据处理更多,可能会影响UI渲染。

MVVM:

在宣布架构组件之后,我们访问了ViewModel,这为我们提供了最大的优势,即它的生命周期感知。如果视图不可用,它不会通知数据。这是一个干净的架构,因为流只处于正向模式,数据将由LiveData自动通知。所以,这是Android推荐的架构。

即使是MVVM也有缺点。由于它是一个生命周期感知,一些概念,如警报或提醒应该在应用程序之外。因此,在这种情况下,我们不能使用MVVM。