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