3 Comments Fluent nHibernate - 01/14/09
I know of many developers that dislike nHibernate just because of the configuration it needs. Come on, it’s not that bad! It’s just a block to add in your config file and a mapping per entity you’ll be using…
Well, it is true that it’s not a lot of fun to create and maintain these mapping files (who likes the ugly XML?).
Everyone of us has -at least- one time:
- - forgot to mark the mapping file as embedded resource
- - forgot to update the mapping when renaming a property
And the most annoying thing of all, is that you can only notice such errors at runtime… But we all just keep up with that because of the sweetness nHibernate brings afterwards!
Even the use of MyGeneration, to generate mapping files based on the database, isn’t a final solution for the mapping files issue. It’s not rare that the database changes physically during development, which would mean you need to regenerate the mapping files each time. At that point, generating the database from the mapping files looks like a great option, but then the manual writing of mapping files comes into the picture again.
Conclusion: It can be a pain to set up nHibernate’s configuration.
Enter fluent nHibernate.
Imagine using a fluent API instead of ugly XML to write your mappings? Wouldn’t that be great?
Well, thanks to Jeremy Miller and James Gregory and of course all other contributors, you now can find the project on Google Code!
Fluent NHibernate solves several problems:
- - Changes won’t make our mappings break, just Ctrl+R+R! (that is if you’re using Resharper, but I’m just assuming you do
)
- - No XML is required to write the mappings, only C#
- - We can actually test the mappings on their own
- - FH allows us to code by convention
Fluent NHibernate solves the mapping problem in two different ways:
- - use a Map-class to manually write the mapping of your entities (=> a Map class per entity)
- - using the Automapping feature of fluent NHibernate
I will demonstrate both ways in upcoming posts. Otherwise I’ll create a post here that’s too long to read.
I’m sure the “i-don’t-use-nhibernate-because-of-the-mappings”-guys, won’t have any reasons to object anymore after I show you how this is done!












[...] Fluent nHibernate [...]
“And the most annoying thing of all, is that you can only notice such errors at runtime⦔
your test suite should alert you to this problem so that is really not so much of an issue IMHO
Yes Davy, you’re right, I also agree that broken mappings should be covered by your tests. My statement is a bit fuzzy here. What I actually meant, is that you can seperate the testing of your mappings and the testing of your operations. You can read more about that in my post about the classic mapping