Posts tagged FluentNHibernate

Automatic domain model persistence – halfway through

Just a quick note. There was no new post yesterday because I was busy implementing automatic persistence for domain model concept-proof. In the previous post I was writing about private field automapping. Since then I managed to implement a bunch of other concepts, including composite elements.

My fork of FluentNHibernate (automapping-fields branch) on github was updated with the most current code version.

DDDSample.NET ‘AutoPersistence’ branch uses the modified FNH to persists its domain model and it works! Without a single mapping file!

So, if everything works fine, why ‘halfway through’? That is because the code is very, very dirty and needs much work before it can be used in production.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Using FluentNHibernate to automaticaly persist your domain model

Yesterday I came across the idea of totally automating domain persistence. There are out there plenty of convention-based persistence frameworks for ActiveRecord (like the Ruby on Rails one), but there is no equivalent solution for the Domain Model (as defined by Eric Evans Blue Book).

Your first thought may be that it is because domain model mapping is complicated. In fact many folks who write about Domain Model point the complexity of mapping as a key difference between DM and AR — the latter is supposed to be limited to one-to-one table to class mapping.

I disagree. In my opinion the difference lies in set of conventions and patterns used to create AR or DM models. While AR uses classes, public properties and relations, DM has its own: entities, value objects, aggregates and so on. The complexity level is comparable when sticking to DM patterns which greatly limit the set of mapping choices. This is the path I want to go.

So, my initiative is to implement Domain Model’s conventions and patterns using FluentNHibernate. I want my persistence mapping be generated straight from domain model without any external help. I want to define my conventions which will limit the possibilities so that automatic mapping is possible. In order to do this I will have to add some metadata to the model, which itself is a nice idea because it will make my models more expressive.

Every journey starts with a first step. I started with the following requirement/story

Private (and possibly readonly) fields can be automatically mapped if there is a corresponding read-only property.

This is not supported out-of-the-box by FluentNHibernate, so I had to fork it and change it. FNH uses a set of rules to map all the features of persistent class. These rules (IAutoMapper implementations) are governed by AutoMapper class. My modification extends the property mapping rule (AutoMapProperty class) so that is uses a set of access strategies to infer the access method of particular property instead of hard-coding property access. Currently (as it is a proof-of-concept) the only supported strategies are Property (formerly built-in) and CamelCase. You can download the modified version of FNH from here (GitHub).

I will be updating a DDDSample.Net branch (I have to create a new one;-)) with results of my work. The next step would be probably relations between aggregates and within an aggregate.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)