Thanks for the links Fabio. I've checked the links along with several similar references to the <id> tag on your blog. I also went back and checked the NHibernate docs.
If I'm understanding the docs and what you've written correctly, all that I need to exclude the POID property is omit the name attribute from the <id> tag. What I'm still not getting is how the mapping knows the database column to use. I guess the fact that the docs say the column attribute is optional is confusing me. Is there a convention in play here? I mean, is the column name being inferred? This blog entry, http://fabiomaulo.blogspot.com/2009/05/nhibernate-versioning.html, seems to suggest that the column name may be being inferred if I'm reading it right. On Sat, Aug 1, 2009 at 6:10 PM, Fabio Maulo <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
