Fluent NHibernate Blog

Fluent NHibernate 1.2 released

2011-04-03T00:00:00+00:00

It’s been a long time coming. Fluent NHibernate 1.2 is now officially released. You can download it from the website downloads page.

The bulk of changes are bugfixes, but we’ve also upgraded to NHibernate 3.1. There’s a few fancy things around access strategies and IEnumerable’s, and some diagnostics thrown in for good measure. For everything else, you can read the release notes.

We’ve also taken ownership of the Fluent NHibernate Nuget package which has been updated for this release.

This will hopefully be the last release of our 1.x code path, which will give us plenty of time to work on some shiny features for 2.0.

Field support (1.1 Feature Focus)

2010-05-23T00:00:00+00:00

Fluent NHibernate has always had an hard-coded restriction on what members you can use for mapping. In some cases this restriction is fairly sensible (static reflection doesn’t support exposing private fields), but in other cases it doesn’t make much sense (automapping).

With the advent of 1.1, we now have full private member support.

ClassMaps

The mapping interface is still limited by the capabilities of expression building, so you still can’t use the traditional Map(x => x.field) syntax to expose fields (private ones, anyway); however, the Reveal functionality is now capable of exposing fields as well as private properties.

Reveal.Member<YourEntity>("_privateField");

Map(Reveal.Member<YourEntity>("_privateField"));

Any method that accepts an Expression can now be used with the above syntax. It’s not compile-safe, but some sacrifices have to be made.

Automapping

The area where these changes really shine is automapping. The automapper is now fully capable of dealing with fields as a legitimate way to persist your entities.

Using the automapping configuration style (highlighted in the automapping configuration feature focus) we’ll instruct the automapper to use fields instead of properties.

public class AppAutomappingCfg : DefaultAutomappingConfiguration
{
  public override bool ShouldMap(Member member)
  {
    return member.IsPrivate && member.IsField;
  }
}

That’s it, your automapper will now only map private fields. You’re obviously fully capable of making your own rules up for what fields should be mapped. You could use a combination of fields and properties, only private fields, fields with certain attributes, etc… It’s up to you.

ComponentMap (1.1 Feature Focus)

2010-05-23T00:00:00+00:00

In the 1.1 release we’ve introduced a new mapping class to help clean up your mappings: the ComponentMap. The ComponentMap is extremely similar to ClassMap and ComponentMap, with the exception that it’s for mapping components.

When you have components that are cropping up in various places across your domain (Address, ContactDetails, Location, etc…), it can be a nuisance to keep repeating the mappings for them. Some people have come up with some clever work arounds for this issue, but hopefully those won’t be necessary now.

Given a common component, we’d map it with the ComponentMap like so:

public class AddressMap : ComponentMap<Address>
{
  public AddressMap()
  {
    Map(x => x.Street);
    Map(x => x.City);
    Map(x => x.State);
    Map(x => x.PostalCode);
  }
}

Then in your ClassMaps or SubclassMaps you just use the bodyless Component method, which indicates to Fluent NHibernate that it should resolve the actual mapping for the component externally.

Component(x => x.Address);

Any place in your domain where you use the above address will receive a copy of the mapping as defined in AddressMap.

If you require a prefix for your component columns, you can use the ColumnPrefix method from the Component method.

Component(x => x.WorkAddress)
  .ColumnPrefix("{property}_");

Note: as with SubclassMap, ComponentMap isn’t (as yet) compatible with the automapper. If you’re using the automapper then you’re better off using the IsComponent configuration option.

Automapping Configuration (1.1 Feature Focus)

2010-05-23T00:00:00+00:00

Automapping is conventional. It’s great when those conventions match up with your own, but how often is that in reality? Nearly everybody needs to configure the automapper to some degree. Some more than others.

Does your automapping configuration look anything like this:

AutoMap.AssemblyOf<Person>()
  .Where(x => x.Namespace.EndsWith("Domain"))
  .IgnoreBase<EntityBase>()
  .Setup(cfg =>
  {
    cfg.FindIdentity = member => member.Name == "EntityId";
    cfg.IsDiscriminated = type => type == typeof(Person);
    cfg.IsComponentType = type => type.In(typeof(Address), typeof(ContactDetails));
    cfg.AbstractClassIsLayerSupertype = type => type == typeof(Client);
  });

Ok, so that’s a pretty big example. Not everyone’s is going to look like that, but they do exist. It’s a bit bloated? How about when you also put it in the context of your overall configuration?

Fluently.Configure()
  .Database(SQLiteConfiguration.Standard.InMemory())
  .Mappings(m =>
  {
    m.FluentMappings.AddFromAssemblyOf<Person>();
    
    m.AutoMappings.Add(
      AutoMap.AssemblyOf<Person>()
        .Where(x => x.Namespace.EndsWith("Domain"))
        .IgnoreBase<EntityBase>()
        .Setup(cfg =>
        {
          cfg.FindIdentity = member => member.Name == "EntityId";
          cfg.IsDiscriminated = type => type == typeof(Person);
          cfg.IsComponentType = type => type.In(typeof(Address), typeof(ContactDetails));
          cfg.AbstractClassIsLayerSupertype = type => type == typeof(Client);
        });
    );
  })
  .BuildSessionFactory();

That’s looking even messier now and, more importantly, a lot more difficult to mentally parse how the automapping is being configured. It’s a big lump of method chaining mess.

The changes that we’ve made for the 1.1 release have introduced the concept of a configuration object for the automapper. Basically, it’s the contents of the Setup method combined with the Where clause, extracted into a separate object. This change greatly reduces the noise in your configuration, gives you a known location for your automapping configuration (rather than having to dig around in your NHibernate session manager code), and increases your ability to replace and inject different configurations.

Lets take a look at how the above is done in 1.1. We’ll start with just the automapping configuration.

The automapping configuration is based on implementing the IAutomappingConfiguration interface; this interface contains several methods that the automapper uses to know how to map your domain. Fear not though, you don’t need to implement all these methods yourself (unless you want to). There’s a DefaultAutomappingConfiguration class which is pre-configured with all the automapping defaults; you can derive from that class and just override whatever options you choose.

public class AppAutomappingCfg : DefaultAutomappingConfiguration
{
  IEnumerable<Type> ignoredTypes = new[] {
    typeof(EntityBase)
  };

  public override bool ShouldMap(Type type)
  {
    if (ignoredTypes.Contains(type))
      return false;

    return type.Namespace.EndsWith("Domain");
  }
  
  public override bool IsDiscriminated(Type type)
  {
    return type == typeof(Person);
  }
  
  public override bool IsComponent(Type type)
  {
    return type.In(typeof(Address), typeof(ContactDetails));
  }
  
  public override bool AbstractClassIsLayerSupertype(Type type)
  {
    return type == tyepof(Client);
  }
}

That’s our application’s automapping configuration. It’s pretty self explanatory really; the only method that might be unfamiliar is ShouldMap(Type), and this is simply a replacement for the Where method. You can see in the ShouldMap method we’ve also got a Contains call on a collection, this is an example of how you could roll the IgnoreBase usage into your configuration; however, this is not required and you are still free to use IgnoreBase if you prefer.

To utilise this new configuration we need to modify our original AutoMap call:

AutoMap.AssemblyOf<Person>(new AppAutomappingCfg());

That’s all there is to our automapping call now, everything’s incorporated in the configuration. Adding a little context, here’s how it now looks in the whole configuration:

Fluently.Configure()
  .Database(SQLiteConfiguration.Standard.InMemory())
  .Mappings(m =>
  {
    m.FluentMappings.AddFromAssemblyOf<Person>();
    
    m.AutoMappings.Add(
      AutoMap.AssemblyOf<Person>(new AppAutomappingCfg())
    );
  })
  .BuildSessionFactory();

Much tidier!

Fluent NHibernate 1.1 Released

2010-05-23T00:00:00+00:00

It’s been a long time coming, but here it is: Fluent NHibernate 1.1.

The primary purpose of this release is to get everyone up-to-date and off the master branch. It comprises of over 200 commits, many bugfixes, and several new features.

You can read the release notes over on the wiki: 1.1 release notes, and an upgrade guide from 1.0RTM.

I’ve put together a few posts highlighting a few of the new features that’ve been slipped into this release.

In keeping with our dependency policy, we’ve upgraded to the latest NHibernate release (2.1.2GA). Support for 3.0 will be added when a GA is available.

I’d like to personally thank the Fluent NHibernate team for all their hard work, as well as the huge ammount of community support we’ve received. Make sure to check out the front page of the Fluent NHibernate website to see the full list of people who’ve contributed.