I said : "an invitation for FNH team to use the Hbm* classes instead generate XML" The invitation can be accepted or refused, that is a FNH's team choice.
The discussion here is about what we will do *for* NHibernate3.0. 2010/1/13 James Gregory <[email protected]> > I have two large concerns about migrating FNH to use the Hbm* classes. > > 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. > > Secondly, last time we attempted to use the Hbm* classes we had an absolute > nightmare dealing with changing versions of NHibernate. The model was > changing between minor versions, and that meant we not only needed to > recompile FNH with the new NH but we had to make code changes too; this made > extremely hard to support multiple versions at the same time. The XML on the > other hand is generally unchanging, or at least completely backwards > compatible, so when a new NH version comes out there's nothing todo apart > from rebuild the solution. > > If you can show me how those points have changed since I last tried it, > then I'll be happy to use it. > > As for the API, well, I'm biased. :) > > > On Wed, Jan 13, 2010 at 6:08 AM, Fabio Maulo <[email protected]> wrote: > >> Hi team. >> >> I would like to have a code re-view of my last post and >> a constructive feedback >> http://fabiomaulo.blogspot.com/2010/01/map-nhibernate-using-your-api.html >> >> >> <http://fabiomaulo.blogspot.com/2010/01/map-nhibernate-using-your-api.html>The >> post, and overall the code, is basically an example about how implement a >> custom API to create mappings by code. >> That is an invitation to everybody want create his own API and even an >> invitation for FNH team to use the Hbm* classes instead generate XML. >> >> That said, seeing how things are going in each framework, NH needs its own >> mapping-by-code. >> Two matters here: >> 1) API definition >> 2) usage of Hbm* or directly create metadata (classes of namespace >> NHibernate.Mapping) >> >> What is clear is that our implementation will supports anything supported >> by XML and, probably, we will improve some of actual >> "conventions-interceptors" (as, for instance, INamingStrategy & Co. ). >> >> -- >> Fabio Maulo >> >> > -- Fabio Maulo
