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