D'Arcy from Winnipeg
Solution Architecture, Business & Entrepreneurship, Microsoft, and Adoption

MVVM Compared To MVC and MVP

Saturday, November 21, 2009 6:53 PM

At the recent Calgary Tech Days event I did a presentation on building composite applications with WPF and Silverlight. One question that I get asked frequently when I get to the part of explaining MVVM is how its different from patterns that seem too similar or identical, with MVC and MVP typically being the two common ones raised.

Usually my answer is that MVVM is very similar to the others, but it implies *stuff* that’s specific to Silverlight and WPF (how binding works, commanding, etc.). Unfortunately without concrete demonstrations of implementing the different patterns, its sometimes hard to verbally get across.

So below I have a comparison, pointing out the key differences between the patterns and why MVVM *is* different.


MVC – Model View Controller

Let’s look at MVC first. You’ll notice a few things about the diagram:

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.

Note the 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. However, my own feeling is that this is a bad practice and creates Franken-ViewModels that have too many responsibilities. It’s better to keep it as a one-to-one mapping instead.

You’ll also notice that the View has no idea about the Model in the MVVM pattern. This is because, as far as the View knows, its “Model” IS the View Model (hence its name). Because of how data-binding and other features like commanding work in WPF and Silverlight, there is rich communication between the View and View Model, isolating the View from having to know anything about what’s really happening behind the scenes.


We could have gone deeper with this discussion, talking about the two different variations of MVP that Martin Fowler describes, or bring in other associated patterns like Front Controller. But at a high level, I think this gives us a good idea of the major differences between the three patterns.

More Reading

Josh Smith has a fantastic article talking about implementing MVVM with WPF and why MVVM is better for WPF (and by extension Silverlight). You can read it here: http://msdn.microsoft.com/en-us/magazine/dd419663.aspx#id0090009



# re: MVVM Compared To MVC and MVP

FYI, in your MVC diagram I think you have the arrow between View/Model backwards. Other than that great post! 11/22/2009 10:08 PM | Dylan Smith

# re: MVVM Compared To MVC and MVP

You're right: the View has a reference to the expected model being provided, but the model doesn't have a reference to the view. I'll have to change that up...or maybe just hope people read these comments? Besides, who uses MVC anyway? It's just a fad...

D 11/22/2009 10:59 PM | D'Arcy from Winnipeg

# re: MVVM Compared To MVC and MVP

In the 1st diagram, it should be ASP.net MVC, instead of MVC. Because in classic MVC, the input point should be View.


10/30/2010 1:52 PM | Prady

# re: MVVM Compared To MVC and MVP

Very very nice post. 3/23/2011 8:06 AM | Prasad

# re: MVVM Compared To MVC and MVP

An excellent post! I believe I shall link to it :) http://thecodersperspective.posterous.com/the-difference-between-mvc-mvp-and-mvvm 4/1/2011 12:26 PM | willem

# re: MVVM Compared To MVC and MVP

Thank you.. It is very nice article.

I went through many articles, but finding variations in the explanitation. I am confused.

Link 1 : http://nirajrules.wordpress.com/2009/07/18/mvc-vs-mvp-vs-mvvm/

The input is directed at the "View" first, not the "Controller".

Link 2 :http://rachelappel.com/comparing-the-mvc-and-mvvm-patterns-along-with-their-respective-viewmodels

Model does not talk/update the view, it talks to controller only.

As you have explained in this article
1. User input to "Controller" not "View"

I have posted this same question in the above mentioned link also, just curious to know the right answer.

Thank you. 5/1/2011 9:27 AM | Vishwanath

# re: MVVM Compared To MVC and MVP

Hi Vishwanath,

Let me explain what I mean in the diagram. When you first try to access an MVC application, you would type something like this:


When that request comes in, the MVC routing engine determines which controller "customers" refers to and directs it to the proper or default method. Its within that method where its determined what view should be rendered.

Let's say you clicked a link on the rendered view to www.somewebsite.com/customerlist. Same thing happens - the routing engine determins which controller "customerlist" is referring to and that controller determines which view gets rendered.

That's one of the biggest diferences between MVC and traditional ASP.NET webform apps - you're not navigating to the location of a page in a folder structure, you're passing a request to a controller that determines what gets rendered.

Hope that helps, let me know if you still have questions.


D'Arcy 5/1/2011 9:41 AM | D'Arcy from Winnipeg

# re: MVVM Compared To MVC and MVP

Hey Vishwanath,

Sorry, I didn't cover your second question. So in the post I mention:

"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."

This is accurate. The view knows information about what model its being passed for binding purposes. However, the view *doesn't* know how to get the model or what context the model is in as far as state. It only knows that it can expect a Customer object, for example, and it has helpers to bind properties of the customer to itself.

I'm a big proponent of using DTO's in this situation and not full fledged entities, so you keep the connection between the view and the back end domain as decoupled as possible.

Let me know if you have any questions on this too.

D 5/1/2011 9:45 AM | D'Arcy from Winnipeg

# re: MVVM Compared To MVC and MVP

Thanks for clarifying my doubts. 5/5/2011 9:53 PM | Vishwanath

# re: MVVM Compared To MVC and MVP

Thanks for your article.

It's very useful 6/8/2011 9:14 AM | M.S.HAQ

# re: MVVM Compared To MVC and MVP

Excellent post. Only MVC diagram is wrong between view/model relationship. 10/4/2011 1:49 AM | Tids

# re: MVVM Compared To MVC and MVP

There are 2 variants of MVP - passive view and supervising controller. I do like your explanations - they are nice and simple. However, for accuracy perhaps you should include both MVP variants. FYI., the MVP variant described in this blog is passive view. 11/16/2011 11:05 PM | ryan bartsch

# re: MVVM Compared To MVC and MVP

Very good explanation. Thanks 12/27/2011 11:59 AM | Thilak

# re: MVVM Compared To MVC and MVP

Thanks for the nice article. it clears few doubts. I still have few additional questions. Can you please help me with in clearing doubts?

a) in MVC , you have shown one way arrow from Controller to Model , which I understand means Controller has reference to model object but model does not have reference to Controller(ideally data is always decoupled). Controller will get data from model and will update the view. Or if View send an update for the data. Controller will update the model and rerender the view.

However in MVP and MVVM, you have double sided arrow , What is the difference in terms of above example? Still presenter has reference to model and will update the view on action at view and rerender view. Why double sided arrow?

b) In MVC, you mentioned in an example, customermodel will have a reference in View but view does not how to fetch data. it is just reference of object.
Is not it same concept in MVP pr MVVM? View should know which entityobject it should bind to or just changing customermodel to object/string native types is making a difference?

I have been searching for an example where a single use case is implemented using all three design patterns so that difference is very clear. But I could not find it. So I am trying to develop it. 1/25/2012 11:55 AM | Manish

# re: MVVM Compared To MVC and MVP

this is the clearest differentiation between these 3 patterns i've found so far. I've used all 3, but could never articulate exactly what the differences were. Especially MVP vs MVC. 2/20/2012 2:59 PM | Raf

# re: MVVM Compared To MVC and MVP

Nice Post. It's clear lot of doubt. 3/2/2012 8:10 PM | shubham

# re: MVVM Compared To MVC and MVP

This is the best comparision i have found .
i have clarified all my doubts in this article.

Thanks alot 4/3/2012 2:43 AM | Savita

# re: MVVM Compared To MVC and MVP

Seems to be good, but i didn't understand anything from the above explanation. Is the MVC explanined in the above it it a ASP.NET MVC or MVC architecture. 4/16/2012 10:40 AM | test user

# re: MVVM Compared To MVC and MVP

Nice explaination :) and very easy to understand. 4/24/2012 7:13 AM | Parikshit

# re: MVVM Compared To MVC and MVP

An article discussing MVVM in the context of ASP.NET MVC 5/6/2012 12:55 PM | jim

# re: MVVM Compared To MVC and MVP

MVC - MVP - MVVM - .... too much design patterns for the same purpose. It seems that we are invented the wheel over and over again.

7/10/2012 10:45 AM | Macheal Ducato

# re: MVVM Compared To MVC and MVP

Patterns like MVVM seem to be a result of overuse of technology, and adaptation by theorists instead of practical developers who put out real products. The MVC is the original design pattern, and it is very abstract in its definition. The lack of State Machines seems to have caused an overuse of patterns. 8/24/2012 10:14 PM | Chet

# re: MVVM Compared To MVC and MVP

Excellent . Tnx a lot . 11/10/2012 9:58 AM | tim

# re: MVVM Compared To MVC and MVP

I wish there were more pages on the net like this that are so beautifully clear, easy to understand and concise.
Thankyou. 1/6/2013 6:40 PM | Jamie Brice

# re: MVVM Compared To MVC and MVP

I saw many of you guys mentioned that the relationship between Model and View in MVC diagram is wrong. One question, if the View have a reference to Model, can anyone please explain how changes in model is transferred back to View.

Thanks. 7/24/2013 6:56 AM | jaliya udagedara

# re: MVVM Compared To MVC and MVP

Hey Jaliya,

Yes, the arrow should be the other way around - the View is aware of the Model, but the Model has no knowledge of any Views that are consuming it.

When you mean changes in the model, do you mean data-wise or structure wise? Structure wise (meaning properties are added/removed/re-named), then the view would need to be re-coded to account for this (assuming if affects how the view renders).

If you meant data-wise (so the data in a Model changes outside the context of a view being rendered), typically you'd need a re-fresh of the web page to get any changes (the web is still stateless in MVC). However, there are other technologies like SignalR that allow for real-time web communication which could facilitate an object being updated while a page is viewed.

Let me know if you have any other questions!

D'Arcy 7/24/2013 7:47 AM | D'Arcy from Winnipeg

# re: MVVM Compared To MVC and MVP

Great article. I got more confused reading so many other articles. This is the only article which gave me clarity. Thank you so much!!! 7/9/2014 4:58 PM | Santosh

Post a comment