castle activeRecord – mookid on code

Why

I have loved NHibernate right from when I first learned how to use it, and I have loved NHibernate beneath Castle ActiveRecord since I found out that ActiveRecord could reduce the pain I felt because of NHibernate’s .hbm.xmhell.

However, using Castle ActiveRecord requires you to “pollute” your otherwise beautiful and pure domain model with database mapping metadata in the form of .NET attributes. If you are a PI kind of kind, this might be too much to ask. But if you (like me) are willing to relax your ideals a bit to gain the extra productivity, you might be happy to do so – even though it hurts your feelings a little bit every time you have to punch in that [Property(Access == PropertyAccess.FieldCamelCase)]-attribute for the 100th time…

But there is another option: Fluent NHibernate – an option that embraces the philosophy of “convention over configuration”, which seems to be getting a lot of attention these days in the .NET world.

EDIT: Oh yeah, and now it’s here.

How

If you know NHibernate, you know that you use it like this:

Create a Configuration.
Use the configuration to build an ISessionFactory which you store somewhere.
And then use that session factory repeatedly to open ISessions which in turn are used to do stuff with the DB.

So, what can Fluent NHibernate do for you? Well, FNH is actually pretty simple – it helps with the Configuration part of NHibernate. As soon as the Configuration is finished, Fluent NHibernate is out, and from then on it’s pure NHibernate again.

First, I will show a short example – and then I will explain how much is actually accomplished by issuing these ridiculously simple statements. Behold:

      var configuration = Fluently.Configure()
        .Database(MsSqlConfiguration
                            .MsSql2005
                            .ConnectionString("server=.;initial catalog=db;integrated security=sspi;"))
        .BuildConfiguration();

      new AutoPersistenceModel()
        .AddEntityAssembly(typeof (Base).Assembly)
        .Where(type => type.Namespace != null && type.Namespace.Contains("Entities"))
        .Setup(s => { s.IsBaseType = t => t == typeof (Base); })
        .Conventions
        .Setup(s => s.AddFromAssemblyOf<Base>())
        .Configure(configuration);

      var sessionFactory = configuration.BuildSessionFactory();

var configuration = Fluently.Configure()

.Database(MsSqlConfiguration

.MsSql2005

.ConnectionString("server=.;initial catalog=db;integrated security=sspi;"))

.BuildConfiguration();

new AutoPersistenceModel()

.AddEntityAssembly(typeof (Base).Assembly)

.Where(type => type.Namespace != null && type.Namespace.Contains("Entities"))

.Setup(s => { s.IsBaseType = t => t == typeof (Base); })

.Conventions

.Setup(s => s.AddFromAssemblyOf<Base>())

.Configure(configuration);

var sessionFactory = configuration.BuildSessionFactory();

If you look at the statements above, I can tell you that it configures FNH to assume the following:

All of my entities can be found in the assembly containing Base inside any namespace containing the string “Entities”.
All of my entities derive from Base, which is just a very simple entity layer supertype containing nothing more than an Id property of type Guid.
Any conventions found in the same assembly as Base will be used by FNH to alter the mappings.

Is that it? Well almost… The code above will make FNH map everything as good as it can, but I still want to alter the mapping in certain places – and that is done through the conventions found in my entity asseembly. At the moment I have 2 conventions:

CascadeAttributeConvention, which is an IHasManyConvention and an IReferenceConvention that looks over any one-to-many and many-to-one relations in my domain, setting cascade to all or all-delete-orphan if it finds a CascadeAttribute on the property.
This allows me to do stuff like

[Cascade] public virtual IList<BandMember> BandMembers { get; set; }

1
2

[Cascade]
public virtual IList<BandMember> BandMembers { get; set; }

and expect the collection of band members to live and die and be updated with its aggregate, Band.
PluralizeTableNamesConvention, which is an implementation of IClassConvention I use to pluralize table names. It contains code like this:

public void Apply(IClassInstance instance) { instance.Table(Pluralize(instance.EntityType.Name)); }

1
2
3
4

public void Apply(IClassInstance instance)
{
instance.Table(Pluralize(instance.EntityType.Name));
}

where the Pluralize method does whichever magic is required to pluralize names from my domain (usually by appending an “s”: Band => Bands, BandMember => BandMembers etc.).

And that is it!

I expect a few more conventions to come along as development progresses – e.g. in other projects I have run into the need to be able to specify that one string should be nvarchar(255) and another string nvarchar(8192) in the DB, which I have solved with an IPropertyConvention that looks for the presence of a LengthAttribute containing the desired length.

And that is why I really like Fluent NHibernate – it allows me to leverage the most powerful ORM alive in the easiest possible way, making NHibernate feel lean and lightweight, encouraging me to follow conventions in my codebase. What’s not to like?

[this post is outdated – too much has happened since the first CTP]

This is the first post in a series of at least four about ASP.NET MVC, which I am planning. The series will show a way to build a nifty web site with a tidy, sound, and scalable architecture. ASP.NET MVC will be used to structure the web site, Castle ActiveRecord will be used for persistence, Castle Windsor for dependency injection, NUnit and NMock for testing, NHaml for the views, and principles from agile, domain-driven design, and test-driven development will be used. The series assumes that you want to use the model-view-controller pattern, so I will not try to convince you that it is a great way to structure a web site 🙂 – even though it is, and currently in my opinion the only sane way to make websites when they contain more than one page…

ASP.NET MVC is a part of the ASP.NET 3.5 Extensions, which is currently only available as a preview. Thus, the details might turn out to be a little off, but still most of the stuff we go through here will apply.

As this is the first post in the series, we will start out by creating a the solution and the project structure – just to get going.
Read more

Category: castle activeRecord

Getting started with Fluent NHibernate

Why

How

Nifty web site with ASP.NET MVC Part 1