Rectangle 27 0

model view controller What is the difference between MVC and MVVM?


  • Controllers listen for, and publish, events. Controllers provide the logic that controls what data is seen and where. Controllers provide the command code to the ViewModel so that the ViewModel is actually reusable.
  • Models hold the actual data (various context, store or other methods)
  • ViewModels hold a certain shape of data and commands, they do not know where the data, or code, comes from or how it is displayed.
  • Views display a certain shape of data. They have no idea where the data comes from.

*Note: in practice Controllers remove most of the logic, from the ViewModel, that requires unit testing. The VM then becomes a dumb container that requires little, if any, testing. This is a good thing as the VM is just a bridge, between the designer and the coder, so should be kept simple.

@Justin: I see my wording of that sentence is a little ambiguous. I actually mean unit-testing for all components is more easily supported, not specifically just improving testing of ViewModels (which as you point out don't actually do that much in MVCVM... which is what you want). The real benefit of controllers is that you are actually removing most of the requirements for testing from the ViewModel (where people keeps shoving controller logic) and putting it where it can be tested (mainly Controllers and Models). The reuse comment is specific to the VMs in that sentence. I have edited it.

@Tomasz Zielinski: True, but "where they are used" was not the question (or the point of my answer). My point is that controllers are still useful in MVVM.

An additional benefit of using an MVCVM model is that only the controller objects need to exist in memory for the life of the application and the controllers contain mainly code and little state data (i.e. tiny memory overhead). This makes for much less memory-intensive apps than solutions where view-models have to be retained and it is ideal for certain types of mobile development (e.g. Windows Mobile using Silverlight/Prism/MEF). This does of course depend on the type of application as you may still need to retain the occasional cached VMs for responsiveness.

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

I agree. My comment was caused by sudden enlightement and not because I disagreed with you.

I have started a blog on this topic which I will add to as and when I can. There are issues with combining MVCVM with the common navigation systems, as most navigation systems just use Views and VMs, but I will go into that in later articles.

Isn't it that MVC is used to architect the whole (web) application, while MVVM is used inside View component of MVC ? So the whole paradigm would be M(VVM)C

The problem is: that to be independently testable*, and especially reusable when needed, a view-model has no idea what view is displaying it, but more importantly no idea where its data is coming from.

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.

Note
Rectangle 27 0

model view controller What is the difference between MVC and MVVM?


[HTTPPOST]   
public ActionResult MyPostBackMethod (myViewModel mvm){
         if (ModelState.IsValid)
        {
               // Immediately call the only method needed in VM...
               mvm.Post()
        }
      return View(mvm);
}
public class myViewModel{
     public string SelectedValue {get;set;}
public void Post(){
    //due to MVC model binding the SelectedValue string above will be set by MVC model binding on post back.
    //this allows you to do something with it.
    DoSomeThingWith(SelectedValue);
    SelectedValue = "Thanks for update!";
 }
}

In clarification of item 6 above (by request)...

  • MVC intercepts the inbound request and routes it to proper controller with strong data type
  • The Model contains DB entities and is very close to the DB Schema it does the queries and filtering. (I like EF and LINQ for this)
  • The Model should also consider repositories and or projection of results into strong types (EF has a great method... EF.Database.Select(querystring, parms) for direct ADO access to inject queries and get back strong types. This addresses the EF is slow argument. EF is NOT SLOW!
  • The ViewModel gets the data and does the business rules and validation
  • The ViewModel is the container for DataContext and view state such as the last selected item etc.
  • The controller is responsible for newing up the ViewModel and injecting it into the View. (for get requests)
  • The controller on post back will cal the ViewModel Post method and wait for results.
  • The controller will inject the newly updated Viewmodel to the View. The View uses only strong type binding.
  • The view merely renders the data, and posts events back to the controller. (see examples below)

Assume a ViewModel like this:

Can you clarify item 6? I realises you are covering ASP.Net only, but it appears to be adding an unwanted dependency to the ViewModel. (e.g. knowledge of where the data comes from/goes to). A code (pseudo-code?) example would be good to clarify this answer and show which parts are server-side and which are client-side.

In this model there is no more HTTP level contact with the request or response objects as MSFT's MVC machine hides it from us.

Note that in order for this actionmethod above to work as you intend, you must have a null CTOR defined that intializes things not returned in the post. The post back must also post back name/value pairs for those things which changed. If there are missing name/value pairs the MVC binding engine does the proper thing which is simply nothing! If this happens you might find yourself saying "I'm losing data on post backs"...

The advantage of this pattern is the ViewModel does all the "clutter" work interfacing to the Model/Buisness logic, the controller is merely a router of sorts. It is SOC in action.

The controller method of the post will look like this (See below), note that the instance of mvm is automatically instanciated by the MVC binding mechanisms. You never have to drop down to the query string layer as a result! This is MVC instantiating the ViewModel for you based on the query strings!

Note
Rectangle 27 0

model view controller What is the difference between MVC and MVVM?


For example: you might use knockout.js and in this case you will have MVVM on your client side. And your MVC's server side can also change. In the complex apps, nobody uses the pure Model. It might have a sense to use a ViewModel as a "Model" of MVC and your real Model basically will be a part of this VM. This gives you an extra abstraction layer.

Well, generally MVC is used in Web development and MVVM is most popular in WPF/Silverlight development. However, sometimes the web architecute might have a mix of MVC and MVVM.

What 'web development' terms 'MVC' is nothing more than separation of concerns and not the authentic MVC that preceded the web.

Note
Rectangle 27 0

model view controller What is the difference between MVC and MVVM?


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.

IMHO I would argue that "making controllers more reusable" is too broad a statement and counter-productive for general ASP.Net "controllers" (i.e. not the business logic layer) as those controllers typically contain the parts of the application that are application-specific. It is the Views, Models, ViewModels and business logic that need to be reusable. I would have thought treating the business logic modules as service providers, not as controllers, would be a better option.

Note
Rectangle 27 0

model view controller What is the difference between MVC and MVVM?


I stated this, in 2009, because far too many people in the community accepted this answer. I said it was debatable, because MVVM and Presentation Model really are the same pattern by different names. Tanks to the popularity in WPF, it's often called MVVM in other frameworks today, but either name is accurate.

In 2009 this answer was probably a good one but today, there is no debate as even HTML Helper controls from MSFT allow for binding using the infamous "For" helpers. Knockout is all about data-binding on the client side.

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.

Note
Rectangle 27 0

model view controller What is the difference between MVC and MVVM?


  • Controllers listen for, and publish, events. Controllers provide the logic that controls what data is seen and where. Controllers provide the command code to the ViewModel so that the ViewModel is actually reusable.
  • Models hold the actual data (various context, store or other methods)
  • ViewModels hold a certain shape of data and commands, they do not know where the data, or code, comes from or how it is displayed.
  • Views display a certain shape of data. They have no idea where the data comes from.

*Note: in practice Controllers remove most of the logic, from the ViewModel, that requires unit testing. The VM then becomes a dumb container that requires little, if any, testing. This is a good thing as the VM is just a bridge, between the designer and the coder, so should be kept simple.

@Justin: I see my wording of that sentence is a little ambiguous. I actually mean unit-testing for all components is more easily supported, not specifically just improving testing of ViewModels (which as you point out don't actually do that much in MVCVM... which is what you want). The real benefit of controllers is that you are actually removing most of the requirements for testing from the ViewModel (where people keeps shoving controller logic) and putting it where it can be tested (mainly Controllers and Models). The reuse comment is specific to the VMs in that sentence. I have edited it.

@Tomasz Zielinski: True, but "where they are used" was not the question (or the point of my answer). My point is that controllers are still useful in MVVM.

An additional benefit of using an MVCVM model is that only the controller objects need to exist in memory for the life of the application and the controllers contain mainly code and little state data (i.e. tiny memory overhead). This makes for much less memory-intensive apps than solutions where view-models have to be retained and it is ideal for certain types of mobile development (e.g. Windows Mobile using Silverlight/Prism/MEF). This does of course depend on the type of application as you may still need to retain the occasional cached VMs for responsiveness.

Even in MVVM, controllers will typically contain all processing logic and decide what data to display in which views using which view models.

For ASP.Net, MVVM is used to two-way bind data within views. This is usually a client-side implementation (e.g. using Knockout.js). MVC on the other hand is a way of separating concerns on the server-side.

For Silverlight and WPF, the MVVM pattern is more encompassing and can appear to act as a replacement for MVC (or other patterns of organising software into separate responsibilities). One assumption, that frequently came out of this pattern, was that the ViewModel simply replaced the controller in MVC (as if you could just substitute VM for C in the acronym and all would be forgiven)...

From what we have seen so far the main benefit of the ViewModel 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.

I agree. My comment was caused by sudden enlightement and not because I disagreed with you.

I have started a blog on this topic which I will add to as and when I can. There are issues with combining MVCVM with the common navigation systems, as most navigation systems just use Views and VMs, but I will go into that in later articles.

Isn't it that MVC is used to architect the whole (web) application, while MVVM is used inside View component of MVC ? So the whole paradigm would be M(VVM)C

The problem is: that to be independently testable*, and especially reusable when needed, a view-model has no idea what view is displaying it, but more importantly no idea where its data is coming from.

The two patterns crop up, in different ways, in both ASP.Net and Silverlight/WPF development.

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.

Note
Rectangle 27 0

model view controller What is the difference between MVC and MVVM?


If you put ten software architects into a room and have them discuss what the Model-View-Controller pattern is, you will end up with twelve different opinions.

@DaniCE Well this is actually the point of WPF's data binding, and the Microsoft invented MVVM, in that one can bypass the controller completely, (claiming the sentence "The controller is being replaced with a View Model" to be incorrect just because there is a controller behind the scenes, is basically like claiming a statement "Higher level language replace the use of cryptic machine code with more readable ones" to be incorrect because behind the scenes machine language is still being used...)

@OmShankar The 11th isn't from yourself. There are 10 total people, and 12 total opinions. The adage is meant to imply that the definitions of these patterns is so open to interpretation that at least two people will be confused enough to have more than one opinion.

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

The sentence "The controller is replaced with a View Model" is not correct. In MVVM what does the role of the controller is databinding (or binding by convention if you use that).

Note
Rectangle 27 0

model view controller What is the difference between MVC and MVVM?


+1. As I commented above, I think that MVC is used to architect the whole (web) application, while MVVM is used inside View component of MVC.

+1. The term is the correct one i think. but about creating hybrid M-MProxy-V-C isn't that too much separation? i think it would be enough using M-V-C whereas M is a Model with full support of Binding. ;)

@ktutnik: Model usually sits on the server, whereas ViewModel lives on the client. So it's no feasible for HTML to bind directly to server-side Model. Therefore we need ModelView which acts as a local, unsaved working set of data extracted from model using e.g. AJAX/JSON.

I apologize but disagree with the MVVM interpretation. A ViewModel has no idea about a View or what a View will look like or how it will respond and a Model likewise has no idea of a ViewModel. In fact, a View shouldn't even know of a Model either, just a ViewModel. Model should represent data and application state, ViewModel should translate the state to UI capable data (I recommend all primitives at this point) and a View should react to the ViewModels translation. The data will often be the same but it should still be wrapped and re-delivered via a ViewModel and no controllers exist.

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 junk, I'm surprised no one has created a hybrid, where your VM is merely a M proxy, and C provides all functionality.

The view does indeed "read" the model data because it's already been put there by the controller. I like to refer to it as a "data injection" by the controller as it's really the controller that is in charge. All the view does in render and fire events in my mind.

Note
Rectangle 27 0

model view controller What is the difference between MVC and MVVM?


In the Model-View-ViewModel design pattern, an app is composed of three general components.

Note that while article referenced applies to development with the Microsoft Stack - Specifically Windows Phone - and XAML, it's doesn't have to be.

You can see an explanation of the MVVM Pattern in the Windows environment:

Note
Rectangle 27 0

model view controller What is the difference between MVC and MVVM?


Agreed. The Viewmodel in MVC "IS" the state machine for the view. It contains the datacontext and tracks all selected item information as well as can contain all validation logic using the IValidatableObject interface. The ViewModel interfaces with the DB at the model layer which can use strong typed models. MVVM in WPF IS the controller of MVC. But the controller of MVC is much cleaner, it is essential a routing handler.

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.

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.

MVVM, strictly speaking, is Presentation Model, though MVVM is becoming the preferred name for the WPF specific realization of the pattern.

Note