NHibernate static proxy

It's been a long time (06/24/2011) I pushed my last commit on my GitHub project NHibernate.StaticProxy, and I notice only now that I even didn't speak about this project on my blog... Shame on me! So after a short delay (hum...), here it comes 🙂

[PostSharp] Ease the creation of configuration sections

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:

[code lang="csharp"]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; } } }[/code] 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?

[PostSharp] [Caliburn] Automatic IEventPublisher subscription and publication

If you develop in WPF using the MVVM pattern, you have certainly heard about the Event Aggregator pattern, which allows, as the MSDN says:

decoupling of publishers and subscribers so they can evolve independently.

There are several implementations of this pattern:

Of course, as the title of this article told you, we are going to use the latter, and I will propose an implementation of a PostSharp aspect which will help us to subscribe to events, publish them, and dispose the subscriptions when the view-model is deactivated.

[PostSharp] Don't NotifyPropertyChanged all properties

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:

[code lang="csharp"]if ( args.Value == args.GetCurrentValue() ) return; args.ProceedSetValue();[/code] 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.

[PostSharp] Fire INotifyPropertyChanged.OnPropertyChanged for read-only properties depending on other properties

One problem of the INotifyPropertyChanged aspect concerns automatic notification of read-only properties which depend on other properties.

Indeed, say you have this class, on which the aspect is applied:

[code lang="csharp"][NotifyPropertyChanged] public class Test { public string FirstName { get; set; } public string LastName { get; set; } public string FullName { get { return FirstName + " " + LastName; } } }[/code] If you change the values of FirstName or LastName, the OnPropertyChanged event will be fired, and the view will be able to display the new values of the properties. But if a control of your view is bound to the FullName property, it won't be updated. A solution would be to declare FullName as an automatic property, and update it in the setters of FirstName and LastName. Not very practical.

In this article, I will show you how to extend the aspect, in order to make it fire the event for dependent properties when a "parent" property is modified.

[PostSharp] How to virtualize all the methods of a class

When using NHibernate, it is recommended to declare the public and protected properties and methods of your entities as virtual, to be able to use them with proxies.

But missing a virtual keyword for a member of a POCO is easily forgettable, and unfortunately, you will only be warned of your mistake on runtime, when your mappings are being built.

In this article, I will show you how to 'not care' anymore about that, and let PostSharp do this stuff for us.

[PostSharp] [FluentValidation] Automatic entity validation with IDataErrorInfo

This post is an english translation of this french post.

One way to manage data validation when using WPF is to implement the interface IDataErrorInfo on the classes to validate, and to modify the XAML file so that WPF automatically uses the functions of this interface to validate the value of the properties (See here for an example).

The problem with this, is that you have to alter your entities to add some logic inside them, which makes them become more than entities. One way to avoid that is provided by FluentValidation, which allows you to deport the validation logic outside of your entities, inside another class, where you can define some validation rules for your entity.

But as we always want our entities to continue to implement IDataErrorInfo, we have to operate a mix with FluentValidation. You can find a way to achieve that in this thread.

This thread was the starting point of the solution I'm going to propose to you, to fix this problematic in an easy way...

[PostSharp] [Caliburn] - Automatically call NotifyOfPropertyChange on the view models

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.