NHibernate - First impressions on ConfORM

Print Content | More

I was very curious when I’ve heard of this project, I’ve used FluentNHibernate as my API to generate mappings in the past, it has its strong and weak points, things I like and things I don’t like much (personal opinions)...so I decided to give ConfORM a try to see how this other option we have works...using a very simple project (like the one I’ll use on my next ‘Linq to NHibernate’ speech at NHDay).

I’ll start with a basic consideration: for legacy databases I still prefer the usual XML mapping for a series of different reasons, but mainly due to the number of special cases you can face during the mapping and I think that the XML representation is more clean and compact to read than anything mapped with an API.

That said, let’s go back to ConfORM. At start I was a bit confused about how ConfORM worked, until I realized that it was following a completely different approach compared to what we were used to do.

ConfORM isn’t just another API that allows you to map you domain classes in NHibernate mimic what you can already do with XML files...it offers you a complete new way of thinking how mapping should be done.

Putting it simple the idea is:

  • You have a set of domain classes.
  • You have your persistence engine (NHibernate).
  • You want a system you can instruct with a series of rules and exceptions that take care of discovering and generating the mappings that describe your domain classes to NHibernate.

This is ConfORM!

And just speaking of it I see a very wide range of possibilities in its application, especially if you have full control over your database, just think of it:

  • Once you have defined your mapping rule-set you can add new classes and have them mapped for free (almost, you always have to deal with exceptions, special cases or fine tunings, but the impact should be minimal).
  • No more directories filled with .hbm.xml files anymore.
  • No more projects or code files dedicated to hold you code mapping files.
  • Consistency in the naming conventions of all the objects that will be generated in the database (if you let NHibernate generate them).
  • You can apply different mapping patterns for different portions of your domain easily.
  • The system itself is highly extensible and you can implement your own patterns starting from those already present.
  • Improved startup time: we can jump over all the XML loading and deserialization stage because ConfORM directly emits NHibernate metadata mappings classes.

Those are some of the things that came into my mind after playing with it for just a couple of days. You need some time to get into the ConfORM view of doing things and it cannot be applied easily to every scenario, especially when dealing with legacy databases (even if it’s flexible enough, but you’ll end up mapping too many exceptions), but it’s another tool we have to define our mappings and I have to say it really impressed me.

The major drawback actually is that the project is in beta stage (but it seems solid enough already) and suffer of a lack of documentation (you can find some introductive posts on Fabio Maulo’s blog and download the whole codebase which contains example of usage...don’t forget it’s another open source project).

In the end of this free talk I asked myself a question: will I use it to define my mappings in production code ? I will for sure give it a serious chance because I really like the approach and I think that with very huge domains, once I got the grasp on it, it can definitely be a time (and life) saving tool.



NHibernate, ConfORM

0 comments

Related Post

All fields are required and you must provide valid data in order to be able to comment on this post.


(will not be published)
(es: http://www.mysite.com)


  1. #1 da http://www.primordialcode.com/blog/post/hands-conform-first-steps

    www.primordialcode.com - Hands on ConfORM: first steps