The advantage, may be, is performance and the possibility of a good refactoring about metadata-creation/modification. The usage of metadata will be a big challenge and a lot of work to do. The usage of Hbm* is more like a joke and will give us the ability to see the XML.
In both cases what we should talk about is the API: what I have used in the post is a "hbm-xml-mimic" style and, IMO, it is the best way for various reasons... Anything here is a team's decision so, please, take your time and have a look to the code. 2010/1/13 Richard Brown (gmail) <[email protected]> > 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 <[email protected]> > *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. >>> >> -- Fabio Maulo
