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.

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.

Answer 2

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

Answer 3

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.

Answer 4

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.