In the last Alt.NET café, about ConfORM, I noticed a confusion about NHibernate’s mappings management.
The image below show a simplified schema of the “mapping process”, the entry-point of some frameworks and the entry point of my examples :
This schema is working since NHibernate 2.0.0GA (2008-08-23)
Between NH2.0.0 and the actual trunk, what we have done is transform the usage of XmlDeserialized from NH’s internal usage in something available, and safe, for external usage but the path is the same since long time.
Give me more context
I know that my friend AjL will ask me “give me more context” so using his post style, here we go:
Mapping Source: How map a class without use XML (12 November 2008)
Map NHibernate using your API (2010/01/11)
Consequence of “Map NHibernate using your API” in our dev-list: thread of 41 mails
ConfORM: NHibernate un-Mapping (2010/02/04)
Public origin of ConfORM idea : thread of 45 mails
As usual if you have some questions, you know where find me.
Just to be clear, when you say it's now possible to use the deserialized HBM objects directly, has all the validation logic that used to be hard coded into the Xml parsing been moved somewhere centralized?
ReplyDeleteNH does not parse the XML. It is only deserialized in (Hbm*) and the XML-Document is thrown. After that (Hbm*) will be bind to mapping-metadata and all instances of (Hbm*) will be thrown. After BuildSessionFactory, metadata are thrown.
ReplyDeleteEach step has its validation.
One more time, the reason why FNH generated Xml in the first place was because there was a large amount of configuration validation logic that was very tightly coupled inside of the NH code that read in hbm xml.
ReplyDeleteMy question for you is: did you move this validation logic deeper inside core NH and out of the Xml importing, or did you simply duplicate it all for ConfORM? As several people have tried over and over again to explain to you, this is the complete reason why FNH never moved off generating Xml.
@JeremyMiller
ReplyDeletethis attitude, and what you said in twitter, needs a specific post.
It's a simple question to answer, Fabio. Yes or no will do. Does using either of the non-xml methods provide the same level of validation as using the xml? Yes or no?
ReplyDeleteFor example, if I don't supply an in the xml, I get an XSD validation error. When I migrated FNH to use HBM classes, if I didn't provide an Id I used to get NullReferenceException's.
@James Gregory
ReplyDeleteThe answer is : NO
As I said each step has its own validation. For example there are "Type" validated at compile-metadata, all named queries are validated at compile-metadata...
If you find a validation needed in a level where the validation is not there you can create a ticket in our JIRA.
Btw the case you said here is only an FNH choose... because NH allow you to work with an entity without have neither a property nor field to represent the ID and you know that it is mandatory for root-entity you should create the HbmId by default and then override it under user request (for a strange casualty it is exactly the ConfORM behaviour).
Thank you for the answer, Fabio.
ReplyDeleteYou are welcome, James.
ReplyDelete