Lately I have been using Fluent NHibernate and NHibernate respectively for my ORM (Object-Relational Mapping) when working on my top secret pet project. Simply put – it’s great. Mapping is done using a fluent C# interface which makes use of lambda expressions for referencing properties instead of strings (check my previous post for more info) so the domain model is safe to refactor because the mapping will be kept up-to-date too.

I spend some time hacking on Fluent NHibernate to add three little features I needed for my integration unit testing via Fluent NHibernate’s PersistenceSpecification. They all currently live in my GitHub(also used by Fluent NHibernate) fork here and have all been submitted upstream. UPDATE: The changes are as of now (21.12.2009) officially part of Fluent NHibernate. I can only hope you will find them useful as well.

PersistenceSpecification: More Informational Error Reporting

Particularly useful to troubleshoot failing mapping integration unit tests when a property check fails it will print both expected and actual types of the values. Also notice that chained properties (object.PropA.PropB) are now supported as well:

For property ‘Nutrition.Calories’ expected ’400′ of type ‘System.Int32′ but got ’400′ of type ‘System.Single’.

instead of:

Expected ’400′ but got ’400′ for Property ‘NutritionCalories’

PersistenceSpecification: Entity Components Property Testing

It is now possible to test entity component properties. For example given this domain model:

public class Food
{
    public Food ()
    {
        Nutrition = new NutritionInfo ();
    }

    public virtual NutritionInfo Nutrition { get; protected set }
    public virtual int Id { get; set; }

}

public class NutritionInfo
{
    public virtual float? Fat { get; set; }
}

and this mapping:

public class FoodMap : ClassMap<Food>
{
    public FoodMap ()
    {
        Id (food => food.Id)
            .GeneratedBy.Native ();

        Component<NutritionInfo> (food => food.Nutrition,
            mapping => {
                mapping.Map (nutrition => nutrition.Fat)
                    .Nullable ();
            }
        ).Access.BackingField ();
    }
}

One can now use this in unit tests:

[TestMethod]
public void Food_Mapping ()
{
    new PersistenceSpecification<Food> (Session)
    .CheckProperty (food => food.Id, 1)
    .CheckProperty (food => food.Nutrition.Fat, 40f) // <-- This one
    .VerifyTheMappings ();

}

Prior to my patch this wasn’t possible because Fluent Nhibernate PersistenceSpecification did not support chained properties and was trying to set a Fat property on the food object. Note that this is useful only for components and not references. For the latter .CheckReference (…) should be used which will also commit the reference to the Database before doing anything else.

PersistenceSpecification: IEqualityComparer for Individual Properties

Given the setup from above it is now possible to set an IEqualityComparer per property, e.g.:

[TestMethod]
public void Serving_Mapping ()
{

    new PersistenceSpecification<Food> (Session, new EqualityComparerForAllProperties ())
    .CheckProperty (food => food.Id, 1)
    .CheckProperty (food => food.Nutrition.Fat, 40f, FloatEqualityComparer.Instance)
    .VerifyTheMappings ();
}

If there is no comparer set for the property it will fall back to using the EqualityComparerForAllProperties and if that is not specified it will just use Object.Equals.

Referencing property names via strings is evil. Consider this simplistic example:

private int _myProperty;

public int MyProperty
{
    get { return _myProperty; }
    set {
        _myProperty = value;
        NotifyPropertyChanged (this, "MyProperty")
    }
}

// Somewhere in a different project or file...
private void NotifyPropertyChanged (object sender, string propertyName)
{
    if (propertyName == "MyProperty")
        Console.WriteLine ("Property Changed");
}

If at some point the property gets renamed the code will compile fine but a bug will be introduced as all those strings that contain the property name will remain unchanged. Evil.

So I have been toying with NHibernate lately and yesterday I was writing some repositories. Let’s assume that theoretically they look like this:

public class Repository <TEntity>
{
    public virtual TEntity FindById (object id)
    {
        ...
    }
}

public class UserRepository : Repository<User>
{
    public IList<User> FindByName (string name)
    {
        // query code
    }

    public IList<User> FindByEmail (string email)
    {
        // query code
    }
}

Both FindByName and FindByEmail in UserRepository will in theory contain the same queries but with different parameters. However I don’t really want to have to write individual queries so I considered a utility method:

public class Repository <TEntity>
{
    public virtual TEntity FindById (object id)
    {
        ...
    }

    protected virtual IList<TEntity> FindByProperty (string propertyName, object value)
    {
        string columnName = NHibernateUtil.GetPropertyColumnName<TEntity> (propertyName);

        // Query here, e.g: "SELECT .... WHERE .... columnName = value" , etc.
    }
}

public class UserRepository : Repository<User>
{
    public IList<User> FindByName (string name)
    {
        return base.FindByProperty ("Name", name);
    }

    public IList<User> FindByEmail (string email)
    {
        return base.FindByProperty ("Email", email);
    }
}

Again this is very bad code and I hated the idea of it, so I sat down and started thinking. I remembered reading somewhere about C# 3.0 Expression Trees so I did some research. When using the special Expression type this seems to tell the compiler to create and expose an AST to us of e.g. a lambda function’s body, so if we pass a property reference expression we can parse the AST and extract the property name from there.

The theory in practice:

public class UserRepository : Repository<User>
{
    public IList<User> FindByName (string name)
    {
        return base.FindByProperty (user => user.Name, name);
    }

    public IList<User> FindByEmail (string email)
    {
        return base.FindByProperty (user => user.Email, email);
    }
}

public class Repository <TEntity>
{
    public virtual TEntity FindById (object id)
    {
        ...
    }

    protected virtual IList<TEntity> FindByProperty (Expression<Func<TEntity, object>> propertyRefExpr,
                                                     object value)
    {
        string propertyName = GetPropertyName (propertyRefExpr);

        // Query code
    }

    private string GetPropertyName (Expression propertyRefExpr)
    {
        if (propertyRefExpr == null)
            throw new ArgumentNullException ("propertyRefExpr", "propertyRefExpr is null.");

        MemberExpression memberExpr = propertyRefExpr.Body as MemberExpression;
        if (memberExpr == null) {
            UnaryExpression unaryExpr = propertyRefExpr.Body as UnaryExpression;
            if (unaryExpr != null && unaryExpr.NodeType == ExpressionType.Convert)
                memberExpr = unaryExpr.Operand as MemberExpression;
        }

        if (memberExpr != null && memberExpr.Member.MemberType == MemberTypes.Property)
            return memberExpr.Member.Name;

        throw new ArgumentException ("No property reference expression was found.",
                         "propertyRefExpr");
    }
}

Also as a helper class:

public static class PropertyUtil
{
    public static string GetPropertyName<TObject> (this TObject type,
                                                   Expression<Func<TObject, object>> propertyRefExpr)
    {
        return GetPropertyNameCore (propertyRefExpr.Body);
    }

    public static string GetName<TObject> (Expression<Func<TObject, object>> propertyRefExpr)
    {
        return GetPropertyNameCore (propertyRefExpr.Body);
    }

    private static string GetPropertyNameCore (Expression propertyRefExpr)
    {
        if (propertyRefExpr == null)
            throw new ArgumentNullException ("propertyRefExpr", "propertyRefExpr is null.");

        MemberExpression memberExpr = propertyRefExpr as MemberExpression;
        if (memberExpr == null) {
            UnaryExpression unaryExpr = propertyRefExpr as UnaryExpression;
            if (unaryExpr != null && unaryExpr.NodeType == ExpressionType.Convert)
                memberExpr = unaryExpr.Operand as MemberExpression;
        }

        if (memberExpr != null && memberExpr.Member.MemberType == MemberTypes.Property)
            return memberExpr.Member.Name;

        throw new ArgumentException ("No property reference expression was found.",
                         "propertyRefExpr");
    }
}

As you can see it contains two generic methods that operate either on types:

string propertyName = PropertyUtil.GetName<User> (u => u.Email);

or instances:

User user = GetUser();
string propertyName = user.GetPropertyName (u => u.Email);

Great, isn’t it? And safe to refactor.

Of course there is no such thing as a free lunch and the use of expression trees comes at the expense of some performance.

BTW is the font size of the code snippets sufficiently readable or is it too tiny?

UPDATE: Added support for Convert expressions (implicit/explicit casting)