There is a demo application from Josh Smith showing usage of M-V-VM pattern in WPF. It’s taken as WPF MVVM foundation and it was published in MSDN magazine here: http://msdn.microsoft.com/en-us/magazine/dd419663.aspx [DemoApp1]
There is another blog entry describing how to migrate it into Silverlight 4 here: http://edventuro.us/2010/03/porting-a-wpf-app-with-the-model-view-viewmodel-design-pattern-to-silverlight-4/ [DemoApp2]
Because of our current project I work on a proof-of-concept for a smart client based on SL4, I used the demo application as a basement and I rewrote it using Caliburn (as an application framework) and FluentValidation (for hte client side validation).
The main differences against the ported demo application [DemoApp2] are:
View resolution/instantiation based on the view-model class types. The idea behind the scene is that the viewmodels are prohibited to talk to any UI specific part and views ( View -> ViewModel/View, ViewModel -> View). When it’s necessary to open another view from the view model, we “activate” the viewmodel or return a subroutine result (a similar concept as with ASP.NET MVC and their ActionResult).
Then it’s necessary to bind the active viewmodel to display a content control in UI.
In this case Caliburn tries to locate some view (based on a convention) to display/present the active viewmodel. You can find more info about it on http://caliburn.codeplex.com/documentation.
The next IMHO improvement is the messaging mechanism in Caliburn. In other words, the messaging is the mechanism how to call any method on viewmodel from the view or how to send a message from the view to the viewmodel. This mechanism replaces usage of commands together with any interactivity definitions (attaching to the event and reacting). More info can be found here: http://caliburn.codeplex.com/documentation. I used it for displaying and handling the list of the menu links.
The viewmodel instatiates the list of the actions.
We bind then the model of the messages to the view like following
The last but not least part is the validation on the client side. A little bit background note: There are 3 different types of the validations:
a) UI validation (in SL done via IDataErrorInfo internface)
b) ViewModel input validation/handling, navigating the user to input the correct data
c) model validation
In Josh’s demo application the viewmodel copies the model’s properties and wraps them + the validation logic spreads among viewmodel and models. Yes, models contains the data, notifications and plus the validation (which could contain the multilanguage support). I think, this is breaking the separation of concerns and that’s the reason I usedFluentValidation to do the validation => I separated the validation concern into the special class(es) with the suffix Validator.
It looks like Silverlights was designed with Close/Close principle (many classes are sealed, internal methods, internal constructors) there are very few parts which we can extend (binding, validation, validation errors, etc. – all are very tightly coupled from the extension point of the view).
So we need to follow stander IDataErrorInfo mechanism to UI support validation. So every model class will need to implement IDataErrorInfo. I had to separate Silverlight infrastructure code into a base class called ValidatableModelBase and my models derive from it. That’s the way where model is not disturbed very much by IDataErrorInfo specifics.
ViewModel exposes a model, called subject. ViewModelValidator<TViewModel> then enables ViewModel properties and their child to be validatable (fullfulling the UI requirements).
[class model]
It’s a concern of the viewmodel validator to decide what (what properties) and when will be validated.
Then ViewModel or any model class is able to validate its properties and return the error message (supporting the multilanguage).
ViewModel (as a validation root) validate method:
The main Validation goals I wanted to fullfill:
a) do not drive the validation by throwing the exceptions
b) viewmodels shouldn’t copy the model properties and wrap them. It increases the amount of the code and complexity in more advanced scenarios
c) models should only hold the data and inform about their changes (INotifyPropertyChanged). Unfortunatelly, they need also derive from the base class which provides the infrastructure code (IDataErrorInfo).
The validation is bigger part and I’d like to provide an additional blog entry only about the validation.
What blog entries will follow:
- connecting the server side with Agatha [preffered] or RRSL Lite in order to communicate with the server + generating the models (entities) for the view model
- unit testing of the client side
- finalizing the server side
- enhancing the client/server with tracing and logging
- client side and server side validation
You can download the code here: MvvmSilverlightDemoApp.zip (after downloading remove the extension txt)
thoughts on coding 