Why Fluent NHibernate vs. hbm XML files?

Question

While this is a subjective question, as a new NHibernate user, I'm curious as to why one would choose Fluent vs traditional XML mapping.

From my standpoint, when I first worked with NHibernate, I used the Fluent interface, but ran into some roadblocks and had a hard time finding adequate documentation for the Fluent interface for anything beyond a 'toy app', so I learned to handle these via XML.

Over time, I realized I did most of my work on the XML side, and realized it was not as horrific as I thought it would be. So for me personally, it was a case of poor documentation and not seeing a significant savings in coding time.

That being said, there may be some huge advantage/disadvantage that I'm missing, and I'd really like to hear some opinions from folks who have more experience in working with these tools.

Amenity

Answer 1

Compile-time safety and refactoring (renaming classes, properties) are one of the benefits you get from fluent mappings. Using one language (C# or VB.NET) to write mappings, program code and data access is another benefit.

Nauseate

I actually have a question on that. I remember that Fluent would throw a nice compile error if my mapping file was off - but would that help if I mistyped a table column, or would I be debugging the exception like I do now when my hbm XML blows up? Thanks for the answer btw! – Amenity

There's nothing to save you if you mistype a table name or column. – Nauseate

Answer 2

• Compile-time name- and type-safety
• IntelliSense to show you which fluent methods are available at any point
• Customizable defaults
• Automapper

Quadricycle

You get IntelliSense in XML as well with the NHibernate XSD Schema. – Nauseate

You get the IntelliSense based on the hibernate schemas, but not based on your object model. – Quadricycle

+1 for automapping, which IMO is the only real "slam dunk". The other benefits are nice, but not mind-blowing. – Await

Answer 3

For me, the big feature in Fluent is the Automapper.

I can define my domain model using POCO classes, (mostly) without worrying about the nasty details of how they will be mapped to tables in a relational database.

As a long time OO developer, and occasional DB developer, I'm much more comfortable designing in an OO fashion. I also believe that this allows me to work at a higher, more powerful level of abstraction.

Automapping also makes ongoing changes to the domain model much less daunting.

Your customers have just told you at the last minute they want to add four new columns to the database?

No problem - add four new properties to the associated POCO (4 lines of code), and remap.

Takes a lot of the pain out of the constantly changing requirements that are a fact of life on many projects.

Roop

Answer 4

I'll add a reason that is very important for making custom functionality based on a common code base:

With fluent you can override mappings to add a new field. Changes to the existing (superclass) mappings are automatically incorporated into the customization/branch. I was forced to use Fluent to avoid maintaining a seperate .hbm/xml file for each customer. Glad I did :)

Inman

Sorry, but can you clarify how is this better than updating the xml ? – Broadax

Answer 5

Like a lot of open source software, this library was available to the public before a lot of the features were production ready. Depending on what version of FluentNhib you were working with, some features may not have been implemented at all. For example, when I first started working with it, composite keys had not been implemented yet and I found stumbling block after stumbling block.

But the product has evolved into quite a great tool. It's pretty feature complete compared to xml and provides all the benefits others have outlined already.

Indium