Another .NET Blog

In this article, I'll show yet another use of PostSharp, this time focusing on the ConfigurationSection class. If you look in the MSDN at the articles which explain how to use the ConfigurationSection, you may have noticed that the code you need to write is repetitive, tedious, and error-prone:

public class PageAppearanceSection : ConfigurationSection
{
	[ConfigurationProperty("remoteOnly", DefaultValue = "false", IsRequired = false)]
	public Boolean RemoteOnly
	{
		get { return (Boolean)this["remoteOnly"]; }
		set	{ this["remoteOnly"] = value; }
	}

	[ConfigurationProperty("font")]
	public FontElement Font
	{
		get	{ return (FontElement)this["font"]; }
		set	{ this["font"] = value; }
	}

	[ConfigurationProperty("color")]
	public ColorElement Color
	{
		get	{ return (ColorElement)this["color"]; }
		set	{ this["color"] = value; }
	}
}

As you can see, you have to put the ConfigurationPropertyAttribute on top of each property, and to make calls to an indexer to the Get and Set methods of the properties, using the same name you used in the attribute.

Doesn't this repetition look like to be a good candidate for an aspect?

By default, Caliburn Micro (CM) doesn't contain the action filters which belong to Caliburn (C). There is a recipe on how to implement them back in CM, but unfortunately it doesn't cover all the initial functionalities which are in C.

One feature missing, and that I needed, is the possibility to depend on "properties of properties".

With the recipe, you can add a dependency between the property of a view-model (VM) and another property of this same VM. Thus, when the latter property is changed, the PropertyChanged event of the VM is fired, resulting in the update of the availability of the action on which the Dependencies attribute is put. But what it doesn't allow you to do, is to define something like:

[Dependencies("OtherProperty.ChildProperty")]

This would update the availability of the action if OtherProperty implements INotifyPropertyChanged and if the ChildProperty is modified. You could even use something like:

[Dependencies("OtherProperty.*")]

which would update the availability if any of the properties of OtherProperty is modified.

But let me show you how I implemented this feature on top of the recipe, with the great use of the Reactive Extensions.

The default behavior of Caliburn Micro (CM), when it must locate a view from a view-model, is very straightforward: it takes the full name of the view-model, replaces the word "Model" by an empty string, and locates a view with this new name.

One problem with this way is that you must exactly have one view per view-model. So, if you have an abstract view-model, with multiple derived view-models, which only set some filters on the displayed data, you must have one view per derived VM. Which is kind of annoying, useless, and error prone.

In this short article, I'll show you how to easily implement a new feature which will allow us to specify, with an attribute on top of the VM, the view we want CM to display when we activate the VM.

One very useful web page I've read before beginning to code on my new project was this one: Data Access - Building a Desktop To-Do Application with NHibernate, from the well-known Ayende. In this article, among other hints and best-practices, he says, at the end of the Managing Sessions chapter:

The recommended practice for desktop applications is to use a session per form, so that each form in the application has its own session. Each form usually represents a distinct piece of work that the user would like to perform, so matching session lifetime to the form lifetime works quite well in practice. The added benefit is that you no longer have a problem with memory leaks, because when you close a form in the application, you also dispose of the session. This would make all the entities that were loaded by the session eligible for reclamation by the garbage collector (GC).

There are additional reasons for preferring a single session per form. You can take advantage of NHibernate’s change tracking, so it will flush all changes to the database when you commit the transaction. It also creates an isolation barrier between the different forms, so you can commit changes to a single entity without worrying about changes to other entities that are shown on other forms.

While this style of managing the session lifetime is described as a session per form, in practice you usually manage the session per presenter.

We'll see now how to implement this behavior, with Caliburn as the MVVM client framework, and Ninject as the dependency injector.

I'm back from 2 weeks of holidays, which partly explains why there wasn't a lot of articles recently.

Now that I'm full of energy, I will have more time to write some new stuff here on this blog. I have a few ideas of the topics I will address, but my next two articles should rely on:

• PostSharp, and an aspect to virtualize all the methods of a class (to be used on POCO classes, so they can be used with NHibernate)
• Ninject, and a solution to use one NHibernate session per View-Model in a WPF application, as recommended by Ayende Rahien here.

After these 2 articles, I don't know yet what I will write about. This is going to be the surprise...

See you soon!

Here, I won't explain what are Caliburn and PostSharp. Their respective documentations, examples and samples already do that very well. But I will show you how to create an aspect which will be applied by PostSharp on the view models of a WPF assembly.

And as a result, on runtime, each time a public property will be changed, the event PropertyChanged of the interface INotifyPropertyChanged will be fired, and the WPF view will be able to refresh its state.

If you already know PostSharp, or have been on their website, you have certainly noticed that they already propose an aspect which intends to implement the interface INotifyPropertyChanged, and to call PropertyChanged when the value of a property is changed.

And if you already know Caliburn, you know that the classes you must inherit from to implement your view models inherit themselves from an abstract class named PropertyChangedBase, which implements INotifyPropertyChanged, and which proposes a function named NotifyOfPropertyChange, to which you give as a parameter the name of the modified property.

The aspect I'm going to show you will allow us to mix these 2 methods.

Dans cet article, je ne vais pas vous expliquer ce que sont Caliburn et PostSharp, leurs documentations et exemples respectifs le font déjà très bien, mais je vais expliquer comment créer un aspect que Postsharp va appliquer à des classes que nous définirons, et qui aura pour résultat d'implémenter l'interface INotifyPropertyChanged dans ces classes, et d'appeler automatiquement l'évènement PropertyChanged lorsque la valeur des propriétés publiques de ces classes va être modifiée.

Si vous connaissez déjà Postsharp, ou avez été regardé sur leur site, vous aurez sûrement remarqué qu'il existe déjà un aspect qui permet d'implémenter l'interface INotifyPropertyChanged, et d'appeler PropertyChanged à chaque changement de valeur de la propriété.

De même, si vous connaissez Caliburn, vous aurez également remarqué que les classes dont vous devez dériver pour implémenter vos ViewModels dérivent elles-même d'une classe abstraite nommée PropertyChangedBase, qui implémente INotifyPropertyChanged, et qui propose une fonction nommée NotifyOfPropertyChange, à laquelle vous passez comme paramètre le nom de la propriété qui a été modifiée.

L'aspect que je vais vous montrer va nous permettre de mixer ces 2 approches.

Pour clore le chapitre sur l'utilisation de Rx pour mon application de gestion de mises à jour, je vais terminer comme annoncé par vous montrer comment je lance les exécutables téléchargés de manière asynchrone, afin de ne pas bloquer le thread de la vue pendant l'installation.

On continue avec la petite série d'articles Rx avec cette fois une nouvelle résolution de "problème". On a vu lors de l'article précédent comment ignorer les erreurs lorsque des adresses de téléchargement étaient invalides ou injoignables. Nous allons voir cette fois-ci comment lancer tous les téléchargements simultanément et comment attendre qu'ils soient tous terminés avant de les exécuter les uns après les autres pour les installer.