views:

205

answers:

4

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

+2  A: 

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.

Reed Copsey
Curious as to why the downvotes...
Reed Copsey
+1  A: 

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

IanR
I am working with code that is written by a one of the guys on Hanselman and Haack's team. Therefore, I presume ViewModel is an acceptable pattern.
MedicineMan
A: 

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.

Syed Hashmi
+2  A: 

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

jbe
could you possibly elaborate more on your answer? I like the direction very much, but I don't feel it completely answers it
MedicineMan
Simple stuff can be done by the ViewModel. It can expose the Model (e.g. Business Object) to the view. It can also interact with services.More complex logic should be handled by the Controller. This might be a database query or a web service request. The results might be passed to a ViewModel so we are able to show it to the user.
jbe