Map to interface without implementation ?Usage of EntityMode.Map and work with dynamic entities ?
2009/8/26 Arne Claassen <[email protected]> > > I have a need to store arbitrary documents (Xml) which have some > required fields that i want to query on. I may later evaluate one of > the many document oriented DBs, but for now, my familiarity with > RDBMS' and desire to use Linq have steered me to use NHibernate. Now > what i've come up with just feels wrong, so i wanted to see if there > are some other hooks in NHibernate that can be used or other ways for > defining the Entities that make this more digestible, or whether my > goals here are what makes this whole thing icky and I need to just > live with that if i really want to store XML blobs. > > My entities implement this interface (where XDoc is a fluent interface > wrapper around XmlDocument): > > public interface IXDocEntity { > XDoc ToDocument(); > void UpdateFromDocument(XDoc document); > } > > The entities have a protected member storing the Xml blob > > protected virtual string Xml { get; set; } > > plus a number of public properties that may be read/write that expose > values inside the Xml, plus some meta-data properties. All these are > accessors for basic entity information and are also required to do > queries for entities in the DB. > > The problem is that information can be set via either a document > change or Property change. Which means I need to propagate the changes > between the two. From document to properties is easy, since that > happens in UpdateFromDocument and that's not under NHibernate control. > But the properties are under NHibernate control, so i can't just add > behavior to the setters (right? There is no way for the NHibernate > generated proxy to call the super setter?). This has lead me to these > three options for handling the problem: > > 1) Make all NHibernate managed properties protected and have the > public properties be proxies under my control... Seems cleanest, but > that's a lot of derivable code that whispers "codegen" and i don't > want to either handcode or codegen that. > 2) Write an Interceptor, like has been described by Ayende et al, for > intercepting property setters and run custom code to update the Xml. > That could be fairly clean and I could use Attributes to mark up the > properties with XPaths to create only one proxy factory for all entity > types. But it seems like my entities now have magic behavior and isn't > having a proxy per entity going to get heavy if that's always used? > 3) Don't update the Xml unless one of two things happens a) a XDoc > operation is requested UpdateFrom or To and b) when the entity is > saved (i.e. set up an event listener). This way we only update Xml > when we need to know that is has changed for display or persistence > > Any other paths or suggestions, other than "OMFG, don't put Xml in a > textblob!!!" :) > > thanks, > arne > > > -- Fabio Maulo --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
