These posts is not exactly what your are looking for but you can use some concepts exposed there http://fabiomaulo.blogspot.com/2008/10/less-than-few-is-gof.html<http://fabiomaulo.blogspot.com/2008/10/less-than-few-is-gof.html> http://fabiomaulo.blogspot.com/2009/07/duck-typing-with-nhibernate.html http://fabiomaulo.blogspot.com/2008/10/entity-name-in-action-entity.html
Look at this old too http://fabiomaulo.blogspot.com/2008/10/less-than-gof-is-hbm.html as you can see you can have a persistent representation of "something" without POCO nor interfaces. I'm sure you can persist your artefacts ;) <http://fabiomaulo.blogspot.com/2008/10/entity-name-in-action-entity.html> 2009/8/27 Arne Claassen <[email protected]> > > Fabio, > > I will have to profess my ignorance on the topics you mentioned. I'm > really only familiar with the poco entities, and that through Fluent > NHibernate. If you have any links that discuss the interface > implementation approach or EntityMode.Map with dynamic entities, i'd > greatly appreciate it. Searches for either have not yielded anything > useful. In particular "interface" and "entity" was something I'd > previously searched a lot about and generally found "don't use > interfaces, use poco classes" or just articles about "fluent interface > for nhibernate". Maybe my google foo just sucks, so a proper lmgtfy > link would be just as appreciated :) > > arne > > On Aug 26, 2:57 pm, Fabio Maulo <[email protected]> wrote: > > 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 > > > -- 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 -~----------~----~----~----~------~----~------~--~---
