Hi Fabio, I've only had a quick look, but it looks OK to me (I realise it's not fluent-style, but I'm not sure it's worth our time trying to make it fluent ... especially when the FNH guys do it so well). I like the idea of being able to use classes like that (and any subsequent conventions) in the NH tests.
Regarding point 2, Is there any advantage in changing it to target NHibernate.Mapping over Hbm*? (I'm guessing no?) James, One of the features I love about FNH is the AutoPersistenceModel.WriteMappingsTo(...) to allow me to see the generated xml ... if you were to move to using the Hbm* classes, I don't think it's just errors you'd want to see, but (somehow) the mapping even when there were no errors. From: James Gregory Sent: Wednesday, January 13, 2010 1:46 PM To: [email protected] Subject: Re: [nhibernate-development] Mapping by code Of course, and it's an invitation I'd like to accept, but only if my previous concerns are no longer relevant. Firstly, a lot of the feedback the user gets (and thus FNH) is from the XSD validation errors. Last time I experimented with the Hbm* classes there was little-to-no validation on the actual model, leading only to NullReferenceException's at runtime if the user forgets to map an Id or anything like that. This was a big stumbling block. It certainly could be avoided by us building a validation layer prior to passing to NHibernate, but that's even more work on-top of the migration.
