@Fabio, This would only work if the values are static correct? I looked at your blog post on this (http://fabiomaulo.blogspot.com/2009/08/from-db- to-ram-wellknowinstancetype.html for those listening) and while this is useful for those unchanging values like countries and so on I am not sure how this could be applied here.
On Jul 31, 9:03 pm, Fabio Maulo <[email protected]> wrote: > In NH you can have an entity without the ID and the ID only for persistence > (without a private filed).In uNhAddIns or in my blog you can find > various examples the last is: > Entity: > public class UserMitaMita > { > public virtual string Name { get; set; } > public virtual Country Country { get; set; }} > > Mapping > <class name="UserMitaMita"> > <id type="int"> > <generator class="hilo"/> > </id> > <property name="Name"/> > <property name="Country" type="Country"/> > </class> > > 2009/7/31 Everett Muniz <[email protected]> > > > > > 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. > > -- > 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 -~----------~----~----~----~------~----~------~--~---
