NHibernate or Fluent NHibernate?

Question

I would be interested in hearing op opinions from others regarding whether which they would choose (no 'neithers' please ;), and why.

What are the downsides to using fluent? (version dependancy maybe?) Pros, Cons, Experiences etc.

Answer 1

Fluent NHIbernate sits on top of NHibernate, so its not really a choice between the two. If youre going to use NHibernate, CHOOSE to use Fluent NH on top of it to save yourself vast amounts of effort.

Fluent NHibernate is awesome, I wouldn't use NHibernate without it. You can fluently map all youy entities (giving you compile time checking, and automated testing support) instead of having to maintain cumbersome xml files and remember their syntax/DTD.

It can also automatically map your entities based on default and/or your own custom conventions.

Just use it!

Answer 2

The advantage of using Fluent NHibernate together with NHibernate is that you get compile time errors if you have messed up your mapping, instead of runtime errors. You also get a much better experience when refactoring your code, since your mappings are kept up to date as you rename properties or whatever, instead of having to remember to manually modify you XML mapping files.

The biggest downside of Fluent NHibernate is that it is still in a quite early phase of its development, and there is quite a big risk of breaking changes as the development of the framework progresses.

Answer 3

Personally I havent really gotten much into fluent nhibernate as I am comfortable with the mapping files. using visual studio to create the mapping files is a breeze and you can set the schema for the xml file which gives you intellisense on the the mapping file. I agree that having compile-time syntax checking is an advantage to using fluent-nhibernate, but I struggle justifing learning the fluent API when I already am familiar with the XML mapping. Perhaps I should just get over my lethergy and learn it already... :-)

Answer 4

I would definitely say go with fluent-nhibernate. Just be aware it may not necessarily be as smooth a ride as you would hope.

1. Regarding version dependency

   1. I have had a 'reverse' dependency issue when upgrading to a new version of FNH required me to upgrade to a new version of NH (2.0 to 2.1 I think). This was not a major issue for me.
   2. I just recently (this morning) dropped NH 2.1.1 into the FNH 1.0 RTM (this is distributed with 2.1.0) without any dramas (yet).

2. Mapping support - some mappings are not yet possible with fluent nhibernate. However, this is NOT a reason to avoid FNH as hybrid fluent-xml mappings allow you to fallback on traditional xml in the event of fluent being unable to map it (although this is only on per-class granularity). Examples of mappings:

   1. Cannot yet map fields - http://groups.google.com/group/fluent-nhibernate/browse_thread/thread/a7787927dafd23a/84ce2616946a18d7
   2. Cannot map some times of dictionary http://groups.google.com/group/fluent-nhibernate/browse_thread/thread/d38b6c72250cd2fb - actually from what I gather this functionality exists but is not in the mainline yet.

3. Compound complexity factor. From the sounds of it you will be learning both FNH and NH at the same time. For the majority of fairly simple applications this is fine - infact FNH is often so good that you need to know fairly little about the hbm.xml mappings. But if you want to go do something reasonably complex, it will rarely work the first time round and you are left wondering if it is a PEBKAC, fluent or NH issue. More often than I'd hoped I ended up writing the traditional xml mappings (of course, you are doing this anyway, but it would have been preferable not to expend more effort than necessary fiddling with fluent first).