Fabio, thanks for the links. I'll see if that sets me on the right path.
Looks like i ought to add your blog to my reader on general principles. arne On Aug 27, 5:33 am, Fabio Maulo <[email protected]> wrote: > These posts is not exactly what your are looking for but you can use some > concepts exposed > therehttp://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.htmlhttp://fabiomaulo.blogspot.com/2008/10/entity-name-in-action-entity.html > > Look at this old > toohttp://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 -~----------~----~----~----~------~----~------~--~---
