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 > >
