Another .NET Blog

I didn't post anything on the blog for a very long time (2010-12-07), so let's break the silence with something new about Caliburn Micro.

In this post, I will briefly show you an update of an "old" article I wrote. The main drawback of the previous version of this dependencies attribute was its inability to make the availability of the action depend on more than one level.

For example, you could write these dependencies, which update the availability of the Do method when either OtherProperty (a property of the same view-model than Do) or OtherProperty.ChildProperty were modified.

[Dependencies("OtherProperty", "OtherProperty.ChildProperty")]
public IEnumerable<IResult> Do()
{

}

With the new Dependencies attribute I'll show you right after the break, you won't be limited to this single level of hierarchy, thus allowing you to write a dependency like:

[Dependencies("OtherProperty.ChildProperty.OneMoreLevelProperty.LastLevelProperty.*")]
public IEnumerable<IResult> Do()
{

}

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?

A small post to warn you that the site may be unavailable a few moment, because I'm currently migrating it on another server.

I hope the transition will be smooth, and won't take too much time.

See you later! (I hope...)

Edit: The migration seems to have been successfully completed. All should be working now :)

This article will show you another improvement which can be made to the DataBinding sample aspect found on SharpCrafters, after the Fire INotifyPropertyChanged.OnPropertyChanged for read-only properties depending on other properties article.

By default, the aspect will fire the PropertyChanged event each time any property is changed. But what if you don't want some of them to fire the event? Or what if, as it happened to me, you set the value of a property, and must do some work in the property setter, even if the new value of the property is the same as the old one?

The latter example is a bit odd, but in the default implementation of the aspect, in the OnPropertySet method, you have this code:

if ( args.Value == args.GetCurrentValue() ) return;

args.ProceedSetValue();

If the new value of the property is the same, the aspect will return, and then never call the args.ProceedSetValue(); method, which will avoid your code to be called in the property setter.

In this short article, I'll show you how to change the aspect, to call the OnPropertyChanged event on all properties, excepted those which are marked with a custom attribute.

As I speak in french on my current twitter account, and because I choosed to write my blog posts in english, I decided to create a new twitter account which would be in english too, and where I would talk almost exclusively about programming, .Net, and the related technologies revolving around it. I hope this will help to ease the creation of interesting discussions with more people.

So here it is.

I hope to see you there !

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.

Eh oui ! Cela fait un moment déjà que l'idée me trotte dans la tête, et je prends enfin cette grande décision: écrire dorénavant tous les articles en anglais.

Ecrire un blog technique sur la programmation, en français, est en soit une bien belle chose. Mais je commençais ces derniers temps à souffrir un peu de ne pas avoir plus de feedback sur ce que j'écris, plus de commentaires. De ne pas pouvoir éventuellement engager des discussions sur les sujets que j'aborde.

Peut-être que le passage à la langue de Shakespeare ne changera rien du tout à cet état de fait. Mais ouvrir ainsi l'audience du site au plus grand nombre devrait quand même, je l'espère, apporter un flux de visiteurs plus conséquent, et donc une probabilité plus importante d'augmenter le nombre d'interactions.

Tous les articles qui ont été écrit jusqu'à maintenant resteront en place, et continueront donc d'être accessibles en français. Mais certains d'entre eux feront en plus l'objet d'une traduction en anglais. Je vais essayer de m'imposer le rythme d'une traduction d'un ancien article à chaque fois que je publie un nouvel article en anglais.

En revanche, les noms des catégories et les tags seront tous traduits, car ce serait improductif d'avoir des doublons à ce niveau là.

Je vous dis donc non pas à bientôt, mais see you soon !

Une manière de gérer la validation des données lorsqu'on utilise WPF est de faire implémenter l'interface IDataErrorInfo par les classes à valider, et de modifier votre fichier XAML pour que WPF utilise automatiquement les fonctions de cette interface pour valider la valeur des propriétés. (Un exemple en action ici).

Le souci avec cette méthode est que vos entités deviennent un peu plus que des entités de base. Et vous vous dites que finalement, ça ne serait pas mal d'externaliser la validation de ces entités dans une autre classe. Et pourquoi pas de définir des règles que votre entité se doit de respecter pour être valide. Pour cela, il existe FluentValidation.

Mais pour continuer à utiliser IDataErrorInfo, on doit maintenant utiliser FluentValidation au sein des fonctions définies par IDataErrorInfo. C'est ce que propose ce thread dans le forum de FluentValidation.

C'est en partant de cet article que je vais vous montrer le cheminement qui m'a amené à utiliser PostSharp pour régler en beauté (j'espère en tout cas) cette problématique.