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