ASP.Net MVC and MVVM

Question

MVVM is a Microsoft design pattern that existed before ASP.Net MVC. Can anyone through light on differences between MVVM and the new MVC pattern?.

Answer 1

I would venture to suggest that MVVM is Microsoft's design pattern and ASP.NET MVC, which is farily recent, is a specific implementation by Microsoft (that doesn't necessarily adhere to either MVC or MVVM but is similar). And as suggested by Reed, MVC has been around since the 70's.

Answer 2

Both MVC & MVVM are architectural patterns. MVC has its roots way back to Smalltalk. ASP.NET MVC is Microsoft's implementation of MVC patter using ASP.NET framework.

Both the patterns deal with separation of concerns. MVC is more to do with the interaction of various commonly used layers in an application like Model (data layer), View (Presentation layer) and Controller (business logic layer).

With advanced databinding capabilities of WPF and Silverlight, MVVM was more suited and publicised as the next big thing. Martin Fowler generalized these patterns as presentation patterns in his Epterprise Application Architechture book.

One advantage I see in using a ViewModel is that it allows you to test the application code better using unit tests. Because of this reason I find MVVM or atleast the ViewModel bit of it being used quite often in ASP.NET MVC applications as well.

Answer 3

Can anyone through light on differences between MVVM and the new MVC pattern?.

Yes: When using ASP.NET MVC the MVC pattern uses the controller to render the model directly into the view. This is perfectly acceptable for trivial projects with a small number of objects. Where this can become a problem is that the concerns of the UI layer can bleed through to the underlying (domain) model.

When using MVVM then you are adding an abstraction between the Model and the View, which is of course the ViewModel. This allows the author to project into the view an object that is most readily consumed by the view. The ViewModel can contain things which would be out of place in the (domain) Model. The cost associated here is that you need to have mapping logic which transposes the data from the model to the View Model. Tools like AutoMapper can assist with this chore.

A simple example of this might be the Model doesn't require certain fields as required, but a particular View does. Rather than baking this logic into the user interface, if it is attached to the ViewModel, then other UI's can consume the same VM without having to duplicate logic that was baked into the first user interface.