thoughts on coding

August 16, 2011

Porting a WPF App with MVVM Design Pattern to Silverlight 4 using Caliburn, FluentValidation

Filed under: .NET, Caliburn, FluentValidation, Silverlight, Uncategorized, WPF/Silverlight — Frantisek @ 7:04 am

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)

 

Advertisements

June 3, 2011

Caliburn(WPF, Silverlight/WP7): Extending the default convetion model to support the convention on more attributes

Filed under: .NET, Caliburn, WPF/Silverlight — Frantisek @ 10:51 pm

I like “convention over configuration/over-specification” approach very much. Caliburn is a briliant framework for building UI layer for Silverlight/WPF/WP7 apps with IoC,DI, extensibility, configurability, etc. using convetions.

We work on a proof of concept how we could (I will use it on my new project) use it. I publish the complete project later. But what I want to decribe here is that Caliburn supports the convetion style with the default property binding and how it would be good to extend it.

Let’s say I have a view model with the property Item which has the properties Title and Description.
So the final result I’d like to achieve is:

 

So XAML for that above result with the default element convention is:

 

Hm, I’m mixing convention and explicit style of definition. That’s not very good, I think. If I argue that Convetions are perfect I would like to use them in more than default situations.

Caliburn supports extensible model of conventions in this way (I write it in BDD style, it’s just for inspiration):

As a developer
I want to extend the default property convetions for new controls so
That I'll be able to use that convetion for new controls.

A possible solution could be:

 as a developer
 I want to extend the ANY! property convetions for ANY! controls
 so that I'll be able to use that convetions in UI layer.

So then I would write in XAML the following:

To support this I had to extend Caliburn convetion model:

  1. IElementConvention has new property

    This will enable to specify both: bindable property(target – where the data will be bound) and identification property (source – specifies what property contains the source data property name)

  2. DefaultElementConvetion which implements IElementConvetion
  3. DefaultConvetionManager which enables to specify both convention-required properties. Example for Textblock control:


    The fist definition code adds the default convention with “Name” as the identification property and “Text” as  the bindable property.
    The second definition code adds the additional convention for Tooltip where bindable and identification properties are same.

  4. method TryCreateApplication – a place where the convetion is tranformed into so called applicable binding and where the value in Identification property is taken as a source for determining the path to bind in the XAML binding.

I’m going to post it to the author of Caliburn if that would be a feature suitable for the framework. I think it culd be because it would enable to extend the default element bindings not only for Name properties but for any such property.

 

That’s all for now ;o)

Create a free website or blog at WordPress.com.