What is the difference between MVC and MVVM?

Question

Is there a difference between the standard "Model View Controller" pattern and Microsoft's Model/View/ViewModel pattern?

Answer 1

ViewModel, from what I can tell, is a different word for Controller.

Answer 2

For one thing, MVVM is a progression of the MVC pattern which uses XAML to handle the display. This article outlines some of the facets of the two.

"The main thrust of the Model/View/ViewModel architecture seems to be that on top of the data (”the Model”), there’s another layer of non-visual components (”the ViewModel”) that map the concepts of the data more closely to the concepts of the view of the data (”the View”). It’s the ViewModel that the View binds to, not the Model directly."

Answer 3

MVVM Model-View ViewModel is similar to MVC, Model-View Controller

The controller is replaced with a View Model. The View Model sits below the UI layer. The View Model exposes the data and command objects that the view needs. You could think of this as a container object that view goes to to get its data and actions from. The View Model pulls its data from the model.

Russel East does a blog discussing more in detail Why is MVVM is different from MVC

Answer 4

MVVM adds the view model into the mix. This is important, as it allows you to use a lot of the binding approach of WPF, without putting all that UI specific pieces in your regular model.

I may be wrong, but I am not sure MVVM really forces the controller into the mix. I find the concept to be more in line with: http://martinfowler.com/eaaDev/PresentationModel.html. I think that people choose to combine it with MVC, not that it is built in into the pattern.

Answer 5

MVVM is a refinement (debatable) of the Presentation Model pattern. I say debatable, because the only difference is in how WPF provides the ability to do data binding and command handling.

Answer 6

Last week was my first presentation while playing the Solution Architect Role in ArabiaGIS, so I tried to start with an introduction to design patterns, and my first subject was the Model-View-ViewModel design pattern. in the presentation I tried to introduce the design pattern concept, showing its importance and the goals off applying it.

The presentation will focus on the history and the importance of MVVM and then go into the detailed of this important design pattern for architecting a WPF application.

To see the presentation: http://solutionsarchitecture.wordpress.com/2009/11/13/introduction-about-mvvm-model-view-viewmodel-design-pattern/

Answer 7

two presentation showing clearly the difference and going more into details: ASP.NET MVC presentation : http://www.jaftalks.com/Home/Show/ASP.NET%20MVC

thank you

Answer 8

The viewmodel is an "abstract" model for your user interface elements. It must allow you to execute the commands, and actions in your view in a non-visual way (for example to test it).

If you have worked with MVC, you probably have sometime found useful to create model objects to reflect the state of your view, for example, to show and hide some edit dialog, etc. In that case you are using a viewmodel.

The MVVM pattern is simply the generalization of that practice to all the UI elements.

And it's not a Microsoft pattern, what appends is that WPF / Silverlight data-bindings are specially well-suited to work with this pattern. But nothing stops you to use it with jave server faces, for example.

Answer 9

I thought one of the main differences was that in MVC, your V reads your M directly, and goes via the C to manipulate the data, whereas in MVVM, your VM acts as an M proxy, as well as providing the available functionality to you V.

If I'm not full of crap, I'm surprised no one has created a hybrid, where your VM is merely a M proxy, and C provides all functionality.

Answer 10

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

Answer 11

From what I can tell, the MVVM maps to the MV of MVC - meaning that in a traditional MVC pattern the V does not communicate directly with the M. In the second version of MVC, there is a direct link between M and V. MVVM appears to take all tasks related to M and V communication, and couple it to decouple it from the C. In effect, there's still the larger scope application workflow (or implementation of the use scenarios) that are not fully accounted for in MVVM. This is the role of the controller. By removing these lower level aspects from the controllers, they are cleaner and makes it easier to modify the application's use scenario and business logic, also making controllers more reusable.

Answer 12

Sorry to have to disagree with such a highly voted answer, but the view-model does not necessarily replace the need for separate controllers.

The problem is that to be independantly testable, and reusable when needed, a view-model has no idea what view is displaying it, but more importantly no idea where it's data is coming from. Even in MVVM, controllers will typically contain all processing logic and decide what data to display in which views using which view models. From what we have seen so far the main benefit of the view model pattern to remove code from XAML code-behind to make XAML editing a more independent task. We still create controllers as and when needed to control (no pun intended) the overall logic of our applications. We also noted that the Sculpture code-gen framework implements MVVM and a pattern similar to Prism AND it also makes extensive use of controllers to separate all use-case logic.

Basically I would encourage caution in assuming controllers are made obsolete by View-models.

Answer 13

Seems to me that MVC is an industry pattern which has proven itself well. While I'm sure MVVM may seem like something new, it appears to be more a Microsoft specific "adaptation" to what is generally used in the industry. In MVC it is common to use additional patterns to help enable component reuse. Among there are Builder, Factory, and Facade.

Isn't it enough to use these? I'd think for simplicity and maintainability it would be better to stick with commonly used and understood patterns. Why is MVVM, which appears to be little more than a refactoring of other design patterns, better? How many different ways do we need to do essentially the same thing?

Answer 14

MVVMC, or perhaps MVC+, seems to be a viable approach for enterprise as well as rapid application development. While it is nice to separate the UI from business and interaction logic, the 'pure' MVVM pattern and most available examples work best on singular views.

Not sure about your designs, but most of my applications, however, contain pages and several (reusable) views and thus the ViewModels do need to interact to some degree. Using the page as controller would defeat the purpose of the MVVM altogether, so not using a "VM-C" approach for the underlying logic might result in .. well .. challenging constructs as the application matures. Even in VB-6 most of us probably stopped coding business logic into the Button event and started 'relaying' commands to a controller, right? I recently looked at many emerging framworks on that topic; my favorite clearly is the Magellan (at codeplex) approach. Happy coding!

http://en.wikipedia.org/wiki/Model_View_ViewModel#References