Thanks for the feedback Mike! I'm still feeling my way along with DDD...and NHibernate. I'm a big believer in the pragmatic compromise but it isn't always easy to tell whether a particular path represents a pragmatic compromise or an ignorant one. ...And nice transformation of the 'cruft' root. My most recent transformation was cruft-acular, as in spectacularly crufty.
On Fri, Jul 31, 2009 at 7:11 PM, Mike Nichols <[email protected]>wrote: > > In DDD, ValueObject is more of a conceptual understanding of an object > and how it is meaningful in the system. You probably already know > that, but I wouldn't be so concerned about introducing an ID into your > ValueObject to try to keep your objects 'cruftless'. You haven't > violated any DDD principles by introducing it if you are careful to > relate to treat them as immutable and important based on their values, > not their identity. Since NH doesn't support subclassing components, > converting them to full-fledged NH Entities is just a valid pragmatic > decision to make IMO. > > On Jul 31, 2:54 pm, Everett Muniz <[email protected]> wrote: > > For those of you doing DDD with NHibernate... > > > > Is it pretty typical to run into scenarios where the way your value > objects > > are used with the domain requires a class mapping with its attendant <id> > > requirement? I guess what I'm asking is whether having to support an ID > > within my value object for the sake of persistence is just a fact of life > > related to the oft-lamented impedance mismatch between objects and > > relational databases? I know I can map the ID to a private field so that > > from the domain point-of-view it doesn't exist but it feels like cruft in > my > > value object. Before I just accept the compromise I wanted to see if I'm > > overlooking something. > > > > If you care about the specific scenario that prompted the question read > on, > > otherwise ignore the rest... > > > > The system we're developing has all sorts of objects related to drawing > and > > many have a color associated with them. Sounds simple I know. The catch > is > > that the color actually used to draw an object in a given context is > > determined by applying a strategy that often depends on the data > associated > > with that drawing context. > > > > So, any object that requires a color (some entities some value objects) > has > > a Color property of type ColorSource. ColorSource is an abstract class > with > > several specializations such as ConstantColorSource and > > SubstringColorSource. These specializations are value objects. > > Any ConstantColorSource/SubstringColorSource instances with the same > > attributes are completely interchangable. > > > > However, when it comes to the persistence mapping in NHibernate the most > > natural way to map the relationship of the various objects that refer to > a > > ColorSource seems to be creating an independent class mapping for > > ColorSource that employs the inheritance mapping features of NHibernate. > > However, the class mapping approach seems to really depend on ID. As > far > > as I can tell NHibernate's answer to value objects is components but I > just > > can't figure out how to accomplish the required mapping using components > w/o > > a whole lot of duplication. > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
