ah... btw the entity UserMitaMita (of the previous mail) is the entity persisted in the DB and does not have a property ID.In that post who has the ID is exactly the in memory wellknow instance (Country).
2009/8/1 Fabio Maulo <[email protected]> > The post is for another stuff. > What I'm saying you is that you can work without declaring a property to > represent the POID in your entities. > In my blog you can find other examples where I'm using an entity without > the ID. > This is another old post > http://fabiomaulo.blogspot.com/2008/11/entities-behavior-injection.html > There you can see an entity with ID and the Invoice entity without ID and > with behaviour injected. > > 2009/8/1 Mike Nichols <[email protected]> > > >> @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<http://fabiomaulo.blogspot.com/2009/08/from-db-%0Ato-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 >> >> >> > > > -- > 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 -~----------~----~----~----~------~----~------~--~---
