Unless Fluent NHibernate is going to replace NHibernate, my vote is for at least a basic grounding in NHibernate, and a mention of the differences between the two.

If you’re trying to teach someone the .hbm.xml way, you would have to cover all kinds of things, like what all the mappings are, that the files have to be embedded resources, that assembly names have to be fully qualified, that you have to specify your unsaved value, how to generate Guid PKs, etc. — all stuff that you don’t have to address in an intro to Fluent NHibernate.

Gotcha, didn’t realize who your target audience was.

Hmmm… I’ve just left a shop that is moving from ADO.NET + Sprocs to NHibernate. Surprisingly I didn’t really have to sell them NHibernate directly, I just used it on a project and it got them curious.

There were four things, I believe, that convinced them NHibernate was seriously worth considering.

1) It has community respect. When they read around, they see influential people praising NHibernate (mostly!). It’s generally respected, trusted and widely used.

2) They noticed that I as adding DAL-related capabilities to our solution in very little time. Things like full text search, caching and switching to a different database platform were possible in minutes. They had just recently spent many man weeks adding these features manually to their code bases.

3) At a big customer sales meeting, it turned out a competitor was leveraging the goodness of _H_ibernate in their enterprise product. This re-enforced the notion that NHibernate *might* be good for their solutions too.

4) They had recently chosen to adopt Target Process for project managment, and realized that this great tool was built on NHibernate. They could see NHibernate being used successfully in the wild (after all, they paid good money for TP).

Unfortunately only one of these factors is really code-related, so I don’t know how useful that is to you.

Back to mappings. I believe the devs grasp the concept of POCO -> XML -> Database quite well, it’s a safe choice.

Not that there aren’t bunches and bunches of these people out there, but I think that all I’m really saying is much the same as some of the other commenters here: FNH is an abstraction over the behavior of NH mapping that the XML makes clear but that FNH can too easily IMHO make look like ‘magic’ and if you don’t take the time to understand what the abstraction is actually DOING for you, you will very quickly bump into its limitations.

I guess as with all abstractions it comes down to this: “is the abstraction so leaky that most people using it will find themselves having to deal with the thing under the abstraction?” and in the case of FNH it seems to me that pretty quickly its early-state limitations will come bubbling out at anyone trying to do ‘real’ work with NH using JUST the FNH approach and they won’t be properly equipped to deal with it because they will lack the foundational knowledge to know what’s going on because they’ve only been introduced to the abstraction.

I’m guessing that with time FNH may indeed reach a maturity level where it can indeed be a whole-hog replacement for any use of XML mapping files (and I for one will rejoice on that day, even as someone who DOES understand the XML and appreciates its power and flexibility) but IMO that day just isn’t here (yet).

I have never said that they’re too stupid to do XML. I just think FNH has a less steep learning curve at first blush. It’s a complicated problem and it’s not quite that simple, but I do think that FNH is more approachable and involves less hassle than the XML.

Already, now that I’ve proceeded down the XML path, I’m realizing what a pain it is and how many gotchas there are (i.e. “oops, forgot about marking it as ‘embedded resource’! — oops, I misspelled the file — “.hmb.xml”, etc, etc, etc). Not having the compiler kick you when you make a mistake can be a real drag when you’re troubleshooting a stupid error like a typo in the file name.

That was my primary concern — easing the transition. I don’t assume anyone is “stupid” except myself.

If the concern is that a dev in the audience cannot grok XML then this is a class of dev that I would strongly argue is NOT a candidate for using NH at all — with or without FNH. If the dev is in this class, then the very next set of problems they will face are challenges with efficient query composition, the n+1 lazy loading issues, improper understanding of either the 1st or 2nd level caches, how UoW behaves, and more.

I am NOT debating the value of FNH (which I think is HIGH), but if its intent was “to make NH approachable for the class of dev that cannot navigate XML” then I think its largely doomed to short-term gain but long-term failure in that you will be able to attract a whole new class of user that will quickly conclude “that NH performs terribly” due to their lack of ability to understand how to configure and implement it efficiently.

Its not clear to me at all that there is a class of dev out there that is both a) frightened to death of XML and b) able to effectively use NH in a production app “if only we could get the XML out of the process”. It may be that your experience in this regard is different from mine, but I haven’t met these people in my own travels :) As such, I think you should carefully consider the skills your audience has and from there determine if they are even candidates for using NH at all (with or without XML or FNH).

Keep in mind, the audience here is likely people who are still rolling their own ADO.NET adapters for stored procedures and have no concept of ORM, let alone any idea to even LOOK for NHibernate in the first place.

This is a gradual introduction into the concept of, “No, you don’t have to write your own ADO.NET layer every project you’re on”

I need to gently coax them into letting go of their datareaders and datasets, etc. Automapping would likely blow their mind.

Starting with Automapping is likely showing someone the “COS” button on a calculator without having taught them basic trigonometry first.

Just show off. Writing the model, then show how to map the whole lot in 2 lines of code with Auto Mappings :)

You could finish by demonstrating something that goes beyond Auto Mapping capabilities. Do that using both .hbm AND Fluent, which would show they can be used side-by-side.

what is the point of starting to teach NHibernate in the year 2009? there are (let me count) ok…there are _zillions_ of guides already avaiable not only on the net.

what the community miss is Fluent NHibernate + NHibernate tutorial and probably some alpha 2.1 LINQ stuff…that would digg deeply. With FNH your chapter 3 can look on generic repository pattern, whereas w/o it your chapter 25 will still only be entitles “and now, mapping our product entity with xml files and inspecting more config options” ;-)
e.g. more to the point guide, and btw, there are many HBML generators out there making teaching HBML deeply pointless…

if it is meant for “learning” you don’t need advanced stuff anyway