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 f开发者_开发知识库or the ViewModels to exist?
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.
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.
This article describes a concrete Architecture for WPF MVVM Applications.
Layers:
- Presentation Layer: Views
- Application Layer: ViewModels
- Domain Layer: Domain specific code
精彩评论