What are the responsibilities of one vs the other? What kind of logic should go in one vs the other? Which one hits services and databases? How do I decide if my code should go in the viewmodel or the controller?
for the record, I am using asp mvc
What are the responsibilities of one vs the other? What kind of logic should go in one vs the other? Which one hits services and databases? How do I decide if my code should go in the viewmodel or the controller?
for the record, I am using asp mvc
Well, MVVM is really a WPF and Silverlight specific design pattern. It specifically relies and requires the data binding, commanding, and templating capabilities of these technologies.
If you are using ASP.NET MVC, MVVM is not an applicable architecture. It, by definition, is built around Model-View-Controller (hence ASP.NET MVC), and uses that architectural design pattern.
I agree with Reed, although, on Hanselminutes recently Phil Haak talked about asp.net MVC 2, and made multiple references to 'ViewModel' - so I inferred that VM's can be created even if you're using MVC
Also - I always think an MVVM app benefits from at least one VM that contains application-wide concerns, such as navigation, which I think of as more of a Controller than a ViewModel...
I am agree with both of you but just like to add another pattern MVP (Model View Presenter) which is best suitable for ASP.Net and Windows form but can't use for WPF and Silverlight. MVVM is specially design for WPF and Silverlight applications.
It's not that uncommon to mix Controllers with ViewModels. In such a scenario you might assign the following responsibilities to the roles:
ViewModel represents the state and behavior of the presentation.
Controller is responsible for the workflow of the application. Furthermore, it mediates between the ViewModels. So it promotes loose coupling by keeping the ViewModels from referring to each other explicitly.
More information about these roles: Link