I Don’t Really See The Problem With NHibernate’s XML Mapping Files
Posted by Davy Brion on January 18th, 2009
Fluent NHibernate is an interesting new project that allows you to configure your NHibernate mappings with a fluent API instead of using the typical XML mapping files. I think it’s great that Fluent NHibernate exists, as there are quite a few people who dislike NHibernate’s mapping files. But i don’t really see why so many people dislike the XML mapping files.
I’ve stated many times before that i seriously dislike having to write a lot of XML just to get something working. Most of that comes from previously having used some of P&P’s older offerings. XML can be easy to read and write or it can be very painful to read and write. I feel that a lot of Microsoft tools which can be configured with XML are typical examples of the painful kind of XML. The old “XML is like violence: if it doesn’t work, apply more!”-joke certainly comes to mind here.
But NHibernate’s mapping XML? I think it’s pretty nice to be honest… it’s not too verbose, and if you add the XSD to Visual Studio’s XSD folder, the Intellisense support is pretty good. When you’re starting out with NHibernate, it might take some time getting used to it, but i don’t think the learning curve (for mapping) is that much higher for the XML mapping than it is for Fluent NHibernate.
A lot of people also say that better refactoring support is a great reason to move to the Fluent NHibernate… that’s true but there’s also a Resharper plugin which supports refactoring NHibernate mapping files.
One reason to stick with the XML mapping files for now is that Fluent NHibernate doesn’t have support (yet) for everything that the XML mapping files allow. This is probably only a temporary issue as Fluent NHibernate seems to be under pretty active development. But if you run into something that isn’t supported yet by Fluent NHibernate, yet is supported by the XML mapping files then you might end up with 2 sources of mapping: most of it in code, and some of it in the XML files. I’d prefer to have all of the mappings in one format/style so that might be an issue until Fluent NHibernate supports everything the NHibernate XML mapping files do.
This is certainly not meant to dissuade people from using Fluent NHibernate. I just prefer to use the XML mapping (for now) and since nobody seems to be sticking up for the XML mapping, i figured i’d stand up 
How about you guys? Do the mapping files really bother you? Or do you prefer the XML over Fluent NHibernate?
January 18th, 2009 at 6:15 pm
I’ll let you get away with trying to say that the Xml mapping isn’t terrifyingly brittle and error prone, but I’ll give you the Fluent NHibernate trump card: Conventions. I can get agressive with the Conventions and/or the AutoPersistenceModel in Fluent NHibernate and do less explicit mapping of any kind. I can almost obviate the very need for that ReSharper plugin for refactoring by just letting the auto mapping + conventions pick up changes in the object model.
January 18th, 2009 at 6:27 pm
auto mapping based on conventions is indeed pretty cool, perhaps this is something we could (optionally) do automatically from within NHibernate
oh and thanks for letting me ‘get away’ with my statements, that’s very gracious of you
January 18th, 2009 at 7:12 pm
Davy,
For me, it is the auto mapping that is key. Being able to have the mapping inferred is immensely powerful
January 18th, 2009 at 7:14 pm
ayende,
we could provide that from within NHibernate, right?
January 18th, 2009 at 9:22 pm
They don’t really bother me, but it sure saves time if you would not need them
January 19th, 2009 at 12:56 am
As one of the fluent nhibernate contributors I am obviously biased, but I will make a few points anyway.
- I think that learning via C# intellisense is easier than xml intellisense. Obviously your mileage will vary depending on how well the API is designed, and I will admit that our API still has plenty of rough edges. That said, I think the discoverable nature of a fluent interface makes for an easier learning experience.
- Typing out your nhibernate mapping in xml requires lots of ctrl+tab as you switch from your domain objects to the xml. It involves lots of copy and paste and there is the chance you will make simple typos. Fluent nhibernate does not suffer from the same problem, because when using it you also get intellisense against your domain objects. Using an xml editor does not offer the same benefit.
- Refactoring support. I know that the resharper plugin exists, but resharper isn’t free. I think that resharper offers a pretty good value proposition and most developers should have a copy, but it is certainly nice to have an option that will allow the more frugal developers to work with nhibernate in a refactoring friendly way.
- As Jeremy and Ayende mentioned, conventions and auto persistence promise to really change how we configure our ORM. Davy, you make the point that NHibernate could provide support for this, and to this my response is simply: ok, why haven’t you? I am not familiar enough with the NH codebase or how the decision making process works so my question is not rhetorical – I would honestly like to know why NH does not have this feature already. Is it simply the case that nobody has tried? Or would the underlying mapping architecture require serious rework to make this possible?
I certainly agree that until Fluent NHibernate has full feature support, hbm xml will sometimes be a better choice.
January 19th, 2009 at 12:58 am
Doh, looks like I failed to close my tag correctly.
January 19th, 2009 at 1:43 am
For my point of views I agreed with Paul Batum said above but I’m wondering why both of contributors don’t collaborate to be a big community.
January 19th, 2009 at 6:37 am
For beginners like me, learning about NHibernate, unit testing, different patterns such as repository and MVC, SOLID principles, all at the same time can produces mental overload more often then I can remember. If I can write mapping files in C# instead of XML, that means less baggage I can forget about. Funny thing is this is coming from someone who is more familiar with VB.NET then C#.
January 19th, 2009 at 6:59 am
“I would honestly like to know why NH does not have this feature already. Is it simply the case that nobody has tried? Or would the underlying mapping architecture require serious rework to make this possible?”
probably because up until now, nobody thought this was important enough to implement… there’s always a lot of work to do in NH-core, and there’s always very few people willing to actually do it.
January 19th, 2009 at 4:28 pm
I kinda agree, the “problems” with the XML were in my view overblown. We used the XML based approach for over 2 years and didn’t feel much pain with it at all.
I do find the convention based approach interesting, and I’d like it if we could add customized conventions (e.g. a set of DDD conventions).
Personally I see the Fluent NH stuff as a small advancement, it won’t change the world but it might be the platform for some cool stuff.
January 19th, 2009 at 5:14 pm
[...] I Don’t Really See The Problem With NHibernate’s XML Mapping Files – Davy Brion [...]
January 20th, 2009 at 12:31 am
Conventions are great…for new projects. But if I’m welding on some new functionality in an existing application, mapping files are a very painless way of getting there. That and the ability to change my mappings (within reason like a column name or something that doesn’t require a new property to my object) without a recompile-deployment.
January 20th, 2009 at 1:06 am
“probably because up until now, nobody thought this was important enough to implement… there’s always a lot of work to do in NH-core, and there’s always very few people willing to actually do it.”
Fair enough.
February 7th, 2009 at 5:29 am
The conventions are cool. The F2 (Rename) support is cool. But there is *very little* pain to be had with the xml files. Let’s be clear, it’s NOT a challenge to maintain them.
May 26th, 2009 at 10:52 am
What I was not able to accomplish with XML was to reuse parts of the mapping.
E.g. An Address class mapped as component in many entities (or Point, or whatever)
With FluentNH I use a custom base class derived from ClassMap for my fluent mapping classes, where I set common mapping properties like Id-, Version, Audit, …
I also have some Extension Methods for the return values of Map(), References(), …where I encapsulate my preferred settings for different mapping elements.
Two extension method examples:
public static IProperty EnumDefaults(this IProperty property)
{
return property.Not.Nullable().CustomTypeIs(); //.Not.Nullable();
}
/// for References
public static ManyToOnePart Defaults(this ManyToOnePart property)
{
return property.Cascade.SaveUpdate().LazyLoad();
}
With this tools I have a single place where I can apply common settings and don’t need to have to maintain the same attributes in each and every XML mapping file.
Automapping and conventions seem interesting but I haven’t used them yet because I’m very comfortable with the explicit mapping and the tools described above.
So FluentNHibernate rocks.