tags:

views:

287

answers:

3

I am kind of new to the whole MVVM pattern, and am trying to wrap my head around it. What I am currently trying to figure out is: in a well structured solution where do the ViewModels live?

Currently my design looks something like this (sort of):

  • Application (The view)
  • DomainSpecificCode (ClassLibrary)
  • Gateways (ClassLibrary)

If I were to add on another type of view (for instance ASP.NET or Silverlight), where would be the best place for the ViewModels to exist?

+2  A: 

ViewModels should go in the Application layer because they tend to be technology-specific.

For example you may want to databind a View attribute to a particular color based on the state of the ViewModel. However, Color is implemented by different types on Windows Forms, ASP.NET and WPF, so you wouldn't be able to reuse the ViewModel accross different technologies.

If you add new Applications, you must also provide new ViewModels.

Mark Seemann
So you are saying the the ViewModel code should live in the same project as the view code? What about in the case of WPF vs Silverlight? If the code is written in such a way that Silverlight can work with it (and I'm not saying it is :( ), should I still write seperate ViewModels for the Silverlight app and the WPF app? (Sorry if these seem like silly questions)
Furis
It could be live in the same project as the View code, or it could live in another project. The important point is that a ViewModel tends to target a specific technology. You may be able to write common ViewModels for WPF and SL since they are so similar, though.
Mark Seemann
Great, thanks for your answer. It sounds to me almost like I should do some tests and see if I can achieve reusability of the ViewModels between SL and WPF. Then I will have a seperate ViewModel project specifically for the case where I go ASP.NET.
Furis
Sounds like a plan :)
Mark Seemann
A: 

Recently, I built a MVVM Desktop application that had 2 flavors:

  • WPF Document Base GUI
  • Console application

Both exe were using the same view models, one was WPF and the other one was not.

I was able to split my solution into the following projects (libraries/exe):

  • non-project related re-usable code (called Common)
  • project models + persistence
  • project view models
  • WPF application + views
  • Console application

It was amazingly easy to build the console application version just by using the View Models. The console application code had less than 200 lines of code, and was basically loading the ProjectViewModel and doing operations on it.

decasteljau
A: 

This article describes a concrete Architecture for WPF MVVM Applications.

Layers:

  • Presentation Layer: Views
  • Application Layer: ViewModels
  • Domain Layer: Domain specific code
jbe