blocks|key|2988519|text|一些基本的区别可以简而言之写成：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2988520|MVC:|offset|length|style|BOLD|2988521|传统的MVC是有一个|2988522|2988523|模型:作为data|ordered-list-item|2988524|视图的模型:处理对用户的视图，可以是UI|2988525|2988526|：控制模型和视图之间的交互，视图调用控制器来更新模型。如果需要，View可以调用多个控制器。|2988527|2988528|MVP:|2988529|类似于传统的MVC，但Controller被Presenter取代。但与Controller不同的是，Presenter还负责更改视图。视图通常不调用演示者。|2988530|MVVM|2988531|这里的区别在于View+Model的存在。它是观察者设计模式的一种实现，其中模型中的更改也由VM在视图中表示。例如:如果更改滑块，不仅模型会更新，视图中显示的可能是文本的数据也会更新。所以有一个双向的数据绑定。|2988532|entityMap^0|0|0|4|0|0|0|0|0|0|0|0|0|4|0|0|0|4|0|0^^$0|@$1|2|3|4|5|6|7|13|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|14|8|@$D|15|E|16|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|17|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|18|8|@]|9|@]|A|$]]|$1|K|3|L|5|M|7|19|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1A|8|@]|9|@]|A|$]]|$1|P|3|-4|5|M|7|1B|8|@]|9|@]|A|$]]|$1|Q|3|R|5|M|7|1C|8|@]|9|@]|A|$]]|$1|S|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|1E|8|@$D|1F|E|1G|F|G]]|9|@]|A|$]]|$1|V|3|W|5|6|7|1H|8|@]|9|@]|A|$]]|$1|X|3|Y|5|6|7|1I|8|@$D|1J|E|1K|F|G]]|9|@]|A|$]]|$1|Z|3|10|5|6|7|1L|8|@]|9|@]|A|$]]|$1|11|3|-4|5|6|7|1M|8|@]|9|@]|A|$]]]|12|$]]

Some basic differences can be written in short:

MVC:

Traditional MVC is where there is a 

<ol>
<li>Model: Acts as the model for data</li>
<li>View : Deals with the view to the user which can be the UI</li>
<li>Controller: Controls the interaction between Model and View, where view calls the controller to update model. View can call multiple controllers if needed. </li>
</ol>

MVP: 

Similar to traditional MVC but Controller is replaced by Presenter. But the Presenter, unlike Controller is responsible for changing the view as well. The view usually does not call the presenter.

MVVM

The difference here is the presence of View Model. It is kind of an implementation of Observer Design Pattern, where changes in the model are represented in the view as well, by the VM. 
Eg: If a slider is changed, not only the model is updated but the data which may be a text, that is displayed in the view is updated as well. So there is a two-way data binding.

blocks|key|2775882|text|来自链接的很好的解释：http://geekswithblogs.net/dlussier/archive/2009/11/21/136454.aspx|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2775883|让我们先来看看MVC|2775884|输入首先指向控制器，而不是视图。该输入可能来自与页面交互的用户，但也可能来自简单地在浏览器中输入特定的url。在任何一种情况下，它都是一个与之交互的控制器，用于启动某些功能。|2775885|在控制器和视图之间存在多对一的关系。这是因为单个控制器可能会根据正在执行的操作选择要呈现的不同视图。|2775886|有一个从控制器到视图的单向箭头。这是因为View对控制器没有任何了解或引用。|2775887|控制器传递回模型，因此在视图和传递给它的预期模型之间有知识，但不是提供它的控制器。|2775888|MVP+-模型视图Presenter|style|BOLD|2775889|现在让我们来看看MVP模式。它看起来与MVC非常相似，除了一些关键的区别：|2775890|输入以视图开始，而不是演示者。|2775891|视图和关联的演示者之间存在一对一的映射。|2775892|视图包含对演示者的引用。演示者还会对从视图触发的事件做出反应，因此它知道与之关联的视图。|2775893|演示者根据它在模型上执行的请求操作更新视图，但视图不能识别模型。|2775894|-模型视图视图模型MVVM|2775895|因此，MVC和MVP模式摆在我们面前，让我们来看看MVVM模式，看看它有什么不同：|2775896|输入从View开始，而不是View+Model。|2775897|虽然视图包含对视图模型的引用，但视图模型没有关于视图的信息。这就是为什么可以在各种视图和一个视图模型…之间建立一对多映射的原因即使是跨技术的。例如，WPF视图和Silverlight视图可以共享同一视图模型。|2775898|entityMap|0|LINK|mutability|MUTABLE|url|http://geekswithblogs.net/dlussier/archive/2009/11/21/136454.aspx^0|B|1T|0|0|0|0|0|0|0|0|I|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1H|8|@]|9|@$A|1I|B|1J|1|1K]]|C|$]]|$1|D|3|E|5|6|7|1L|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|1M|8|@]|9|@]|C|$]]|$1|H|3|I|5|6|7|1N|8|@]|9|@]|C|$]]|$1|J|3|K|5|6|7|1O|8|@]|9|@]|C|$]]|$1|L|3|M|5|6|7|1P|8|@]|9|@]|C|$]]|$1|N|3|O|5|6|7|1Q|8|@$A|1R|B|1S|P|Q]]|9|@]|C|$]]|$1|R|3|S|5|6|7|1T|8|@]|9|@]|C|$]]|$1|T|3|U|5|6|7|1U|8|@]|9|@]|C|$]]|$1|V|3|W|5|6|7|1V|8|@]|9|@]|C|$]]|$1|X|3|Y|5|6|7|1W|8|@]|9|@]|C|$]]|$1|Z|3|10|5|6|7|1X|8|@]|9|@]|C|$]]|$1|11|3|12|5|6|7|1Y|8|@]|9|@]|C|$]]|$1|13|3|14|5|6|7|1Z|8|@]|9|@]|C|$]]|$1|15|3|16|5|6|7|20|8|@]|9|@]|C|$]]|$1|17|3|18|5|6|7|21|8|@]|9|@]|C|$]]|$1|19|3|-4|5|6|7|22|8|@]|9|@]|C|$]]]|1A|$1B|$5|1C|1D|1E|C|$1F|1G]]]]

Great Explanation from the link : <a href="http://geekswithblogs.net/dlussier/archive/2009/11/21/136454.aspx">http://geekswithblogs.net/dlussier/archive/2009/11/21/136454.aspx</a>

Let's First look at MVC

The input is directed at the Controller first, not the view. That input might be coming from a user interacting with a page, but it could also be from simply entering a specific url into a browser. In either case, its a Controller that is interfaced with to kick off some functionality.

There is a many-to-one relationship between the Controller and the View. That’s because a single controller may select different views to be rendered based on the operation being executed.

There is one way arrow from Controller to View. This is because the View doesn’t have any knowledge of or reference to the controller.

The Controller does pass back the Model, so there is knowledge between the View and the expected Model being passed into it, but not the Controller serving it up.

MVP – Model View Presenter

Now let’s look at the MVP pattern. It looks very similar to MVC, except for some key distinctions:

The input begins with the View, not the Presenter.

There is a one-to-one mapping between the View and the associated Presenter.

The View holds a reference to the Presenter. The Presenter is also reacting to events being triggered from the View, so its aware of the View its associated with.

The Presenter updates the View based on the requested actions it performs on the Model, but the View is not Model aware.

MVVM – Model View View Model

So with the MVC and MVP patterns in front of us, let’s look at the MVVM pattern and see what differences it holds:

The input begins with the View, not the View Model.

While the View holds a reference to the View Model, the View Model has no information about the View. This is why its possible to have a one-to-many mapping between various Views and one View Model…even across technologies. For example, a WPF View and a Silverlight View could share the same View Model.

blocks|key|2988635|text|MVC、MVP、MVP|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|2988636|MVC+(旧的)|2988637|MVP+(更模块化，因为它的低耦合性。演示者是视图和模型之间的中介者)|2988638|MVVM+(您已经在VM和UI组件之间进行了双向绑定，因此它比MVP更自动化)|2988639|📷|atomic|2988640|​|2988641|另一张图片：|2988642|2988643|2988644|entityMap|0|IMAGE|mutability|IMMUTABLE|imageUrl|https://ask.qcloudimg.com/http-save/yehe-900000/26472a964d8bb9f5b691e3e38c164ae0.png|imageAlt|1|https://ask.qcloudimg.com/http-save/yehe-900000/162ed8ed92ba46b499ae03f5179796d3.png^0|0|B|0|0|0|0|0|1|0|0|0|0|0|1|1|0|0^^$0|@$1|2|3|4|5|6|7|15|8|@$9|16|A|17|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|18|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|19|8|@]|D|@]|E|$]]|$1|J|3|K|5|6|7|1A|8|@]|D|@]|E|$]]|$1|L|3|M|5|N|7|1B|8|@]|D|@$9|1C|A|1D|1|1E]]|E|$]]|$1|O|3|P|5|6|7|1F|8|@]|D|@]|E|$]]|$1|Q|3|R|5|6|7|1G|8|@]|D|@]|E|$]]|$1|S|3|M|5|N|7|1H|8|@]|D|@$9|1I|A|1J|1|1K]]|E|$]]|$1|T|3|P|5|6|7|1L|8|@]|D|@]|E|$]]|$1|U|3|-4|5|6|7|1M|8|@]|D|@]|E|$]]]|V|$W|$5|X|Y|Z|E|$10|11|12|-4]]|13|$5|X|Y|Z|E|$10|14|12|-4]]]]

MVC, MVP, MVVM
MVC (old one)
MVP (more modular because of its low-coupling. Presenter is a mediator between the View and Model)
MVVM (You already have two-way binding between VM and UI component, so it is more automated than MVP)
<a href="https://i.stack.imgur.com/CFbNC.png" rel="noreferrer"><img src="https://i.stack.imgur.com/CFbNC.png" alt="enter image description here" /></a>
Another image:
<a href="https://i.stack.imgur.com/ENBf1.png" rel="noreferrer"><img src="https://i.stack.imgur.com/ENBf1.png" alt="enter image description here" /></a>

blocks|key|171077|text|下图来自Erwin+van+der+Valk编写的article：|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|171078|​|171079|📷|atomic|171080|171081|article解释了其中的差异，并给出了一些C#代码示例|171082|entityMap|0|LINK|mutability|MUTABLE|url|https://blogs.msdn.microsoft.com/erwinvandervalk/2009/08/14/the-difference-between-model-view-viewmodel-and-other-separated-presentation-patterns/|1|IMAGE|IMMUTABLE|imageUrl|https://ask.qcloudimg.com/http-save/yehe-900000/549a3937ed4940ba01de32768febe32a.png|imageAlt|2^0|P|7|0|0|0|0|1|1|0|0|0|7|2|0^^$0|@$1|2|3|4|5|6|7|10|8|@]|9|@$A|11|B|12|1|13]]|C|$]]|$1|D|3|E|5|6|7|14|8|@]|9|@]|C|$]]|$1|F|3|G|5|H|7|15|8|@]|9|@$A|16|B|17|1|18]]|C|$]]|$1|I|3|E|5|6|7|19|8|@]|9|@]|C|$]]|$1|J|3|K|5|6|7|1A|8|@]|9|@$A|1B|B|1C|1|1D]]|C|$]]|$1|L|3|-4|5|6|7|1E|8|@]|9|@]|C|$]]]|M|$N|$5|O|P|Q|C|$R|S]]|T|$5|U|P|V|C|$W|X|Y|-4]]|Z|$5|O|P|Q|C|$R|S]]]]

The image below is from the <a href="https://blogs.msdn.microsoft.com/erwinvandervalk/2009/08/14/the-difference-between-model-view-viewmodel-and-other-separated-presentation-patterns/" rel="nofollow noreferrer">article</a> written by Erwin van der Valk:

<img src="https://i.stack.imgur.com/Y82D3.png" alt="image explaining MVC, MVP and MVVM - by Erwin Vandervalk">

The <a href="https://blogs.msdn.microsoft.com/erwinvandervalk/2009/08/14/the-difference-between-model-view-viewmodel-and-other-separated-presentation-patterns/" rel="nofollow noreferrer">article</a> explains the differences and gives some code examples in C#

blocks|key|2776086|text|MVP:|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|2776087|的优势：|2776088|展示者将出现在模型和view.Presenter之间，将从模型中提取数据，并根据视图的需要对数据进行操作，并将其提供给视图，视图只负责渲染。|2776089|Disadvantages:|2776090|1)我们不能对多个模块使用presenter，因为presenter中的数据正在被一个视图类修改。|2776091|3)破坏干净的架构，因为数据流应该只向外流动，但这里的数据是从presenter返回到View。|2776092|MVC:|2776093|公告：|2776094|在这里我们有控制器在视图和model.Here之间，数据请求将从控制器到视图，但数据将以接口的形式发送回视图，而不是使用controller.So，在这里控制器不会因为许多事务而变得臃肿。|2776095|Disadvantagaes:|2776096|数据操作应该由View来完成，这将是UI线程上的额外工作，如果数据处理更多，这可能会影响UI渲染。|2776097|多虚拟机：|2776098|在宣布架构组件后，我们访问了ViewModel，这给我们提供了最大的优势，即它的生命周期aware.So，如果视图不是available.It，它不会通知数据。LiveData是一个干净的体系结构，因为flow只处于转发模式，数据将由LiveData自动通知。因此，它是Android推荐的架构。|2776099|即使是MVVM也有disadvantage.。由于它是生命周期感知的，一些概念，如警报或提醒，应该来自app.So之外，在这种情况下，我们不能使用MVVM。|2776100|entityMap^0|0|4|0|0|4|0|0|0|E|0|0|0|0|4|0|0|3|0|0|0|F|0|0|0|5|0|0|9|C|0^^$0|@$1|2|3|4|5|6|7|17|8|@$9|18|A|19|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|1A|8|@$9|1B|A|1C|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|1D|8|@]|D|@]|E|$]]|$1|J|3|K|5|6|7|1E|8|@$9|1F|A|1G|B|C]]|D|@]|E|$]]|$1|L|3|M|5|6|7|1H|8|@]|D|@]|E|$]]|$1|N|3|O|5|6|7|1I|8|@]|D|@]|E|$]]|$1|P|3|Q|5|6|7|1J|8|@$9|1K|A|1L|B|C]]|D|@]|E|$]]|$1|R|3|S|5|6|7|1M|8|@$9|1N|A|1O|B|C]]|D|@]|E|$]]|$1|T|3|U|5|6|7|1P|8|@]|D|@]|E|$]]|$1|V|3|W|5|6|7|1Q|8|@$9|1R|A|1S|B|C]]|D|@]|E|$]]|$1|X|3|Y|5|6|7|1T|8|@]|D|@]|E|$]]|$1|Z|3|10|5|6|7|1U|8|@$9|1V|A|1W|B|C]]|D|@]|E|$]]|$1|11|3|12|5|6|7|1X|8|@]|D|@]|E|$]]|$1|13|3|14|5|6|7|1Y|8|@$9|1Z|A|20|B|C]]|D|@]|E|$]]|$1|15|3|-4|5|6|7|21|8|@]|D|@]|E|$]]]|16|$]]

MVP:
Advantages:
Presenter will be present in between Model and view.Presenter will fetch data from Model and will do manipulations for data as view wants and give it to view and view is responsible only for rendering.
Disadvantages:
1)We can't use presenter for multiple modules because data is being modified in presenter as desired by one view class.
3)Breaking Clean architecture because data flow should be only outwards but here data is coming back from presenter to View.
MVC:
Advanatages:
Here we have Controller in between view and model.Here data request will be done from controller to view but data will be sent back to view in form of interface but not with controller.So,here controller won't get bloated up because of many transactions.
Disadvantagaes:
Data Manipulation should be done by View as it wants and this will be extra work on UI thread which may effect UI rendering if data processing is more.
MVVM:
After announcing Architectural components,we got access to ViewModel which provided us biggest advantage i.e it's lifecycle aware.So,it won't notify data if view is not available.It is a clean architecture because flow is only in forward mode and data will be notified automatically by LiveData. So,it is Android's recommended architecture.
Even MVVM has a disadvantage. Since it is a lifecycle aware some concepts like alarm or reminder should come outside app.So,in this scenario we can't use MVVM.

blocks|key|173251|text|MVC+vs.MVVM+vs.|type|unstyled|depth|inlineStyleRanges|entityRanges|data|173252|MVC+-模型视图控制器|173253|View(.xml,+.storyboard)+-+Controller(Activity,+Controller)+-+Model(Others)|code-block|syntax|javascript|173254|视图渲染UI控制器与视图绑定|173255|MVP+-模型视图演示者|173256|View(.xml,+.storyboard,+Activity,+Controller)+-+Presenter(plain+Class)+-+Model(Others)|173257|ModelView+-查看模型MVVM|173258|View(.xml+with+data,+view.swift)+-+ModelView(ViewModel,+ObservableObject)+-+Model(Others)|173259|安卓DataBinding，SwiftUI|173260|MVVM基于观察值使用data+binding或two+way+data+binding连接视图和ModelView|offset|length|style|CODE|173261|有时在UI世界(iOS，Android)中，您可以找到负责导航和设置依赖项的附加对象(路由器、导航器、协调器|173262|entityMap^0|0|0|0|0|0|0|0|0|0|B|C|O|K|0|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|15|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|16|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|17|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|18|8|@]|9|@]|A|$]]|$1|M|3|N|5|F|7|19|8|@]|9|@]|A|$G|H]]|$1|O|3|P|5|6|7|1A|8|@]|9|@]|A|$]]|$1|Q|3|R|5|F|7|1B|8|@]|9|@]|A|$G|H]]|$1|S|3|T|5|6|7|1C|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1D|8|@$W|1E|X|1F|Y|Z]|$W|1G|X|1H|Y|Z]]|9|@]|A|$]]|$1|10|3|11|5|6|7|1I|8|@]|9|@]|A|$]]|$1|12|3|-4|5|6|7|1J|8|@]|9|@]|A|$]]]|13|$]]

MVC vs MVP vs MVVM
MVC - Model View Controller
<pre><code>View(.xml, .storyboard) - Controller(Activity, Controller) - Model(Others)
</code></pre>
View - rendering UI
Controller is bound with View
MVP - Model View Presenter
<pre><code>View(.xml, .storyboard, Activity, Controller) - Presenter(plain Class) - Model(Others)
</code></pre>
MVVM - View Model ModelView
<pre><code>View(.xml with data, view.swift) - ModelView(ViewModel, ObservableObject) - Model(Others)
</code></pre>
Android DataBinding, SwiftUI
MVVM uses <code>data binding</code> or <code>two way data binding</code> to connect View and ModelView based on Observation
Sometimes in UI world(iOS, Android) you can find additional object(Router, Navigator, Coordinator) which is responsible for navigation and setting dependencies

If we search Google using the phrase &quot;differences between MVC, MVP &amp; MVVM design pattern&quot; then we may get a few URL's which discuss <a href="https://forums.asp.net/t/1944181.aspx?What%20is%20difference%20between%20MVC%20MVP%20MVVM%20design%20pattern" rel="noreferrer">the difference between MVC MVP &amp; MVVM design pattern theoretically like</a>:
MVP
Use in situations where binding via a &quot;dataContext&quot; is not possible.
Windows Forms is a perfect example of this. In order to separate the view from the model, a presenter is needed. Since the view cannot directly bind to the presenter, information must be passed to the view via an interface (IView).
MVVM
Use in situations where binding via a &quot;dataContext&quot; is possible. Why? The various IView interfaces for each view are removed which means less code to maintain.
Some examples where MVVM is possible to include WPF and javascript projects using Knockout.
MVC
Use in situations where the connection between the view and the rest of the program is not always available (and you can’t effectively employ MVVM or MVP).
This clearly describes the situation where a web API is separated from the data sent to the client browsers. Microsoft’s ASP.NET MVC is a great tool for managing such situations and provides a very clear MVC framework
<hr />
But I have not found a single article which discusses the difference theoretically along with sample code.
It would be really nice if I get an article that discusses the difference between these 3 design patterns (MVC, MVP &amp; MVVM) along with code.
I'd like to get my hands on the source code of 3 similar CRUD apps that have been implemented by these three design patterns (MVC, MVP &amp; MVVM). So that I can go through the code and understand how one should write code for these three design pattern (MVC, MVP &amp; MVVM).
So if any such article exists which discusses how code would look different for these 3 design patterns (MVC, MVP &amp; MVVM) then please redirect me to that article.

What is difference between MVC, MVP & MVVM design pattern in terms of coding c#

虚拟机

路由器

数据流

Android

Windows

路由

如果我们用“MVC、MVP和MVVM设计模式之间的差异”这个短语在谷歌上搜索，我们可能会得到一些讨论的网址MVP在无法通过"dataContext“进行绑定的情况下使用。Windows窗体就是一个很好的例子。为了将视图与模型分开，需要一个presenter。由于视图不能直接绑定到presenter，因此必须通过接口(I...

问MVC、MVP和MVVM设计模式在编码c#方面有什么不同？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问MVC、MVP和MVVM设计模式在编码c#方面有什么不同？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问MVC、MVP和MVVM设计模式在编码c#方面有什么不同？
EN