(2) <<based on my understanding, you're only option is to provide the complete component mapping in each of the class mappings that want to use it. that can be a lot of duplication depending on the scenario (and it is in mine)>>
http://www.nhforge.org/doc/nh/en/index.html#mapping-types-custom ________________________________ Från: [email protected] [[email protected]] för Everett Muniz [[email protected]] Skickat: den 4 augusti 2009 14:48 Till: [email protected] Ämne: [nhusers] Re: DDD, value objects and IDs Hey John, I appreciate the feedback. Component is indeed a good way to get value object behavior but based on what I can tell it's limited in 2 ways: (1) it doesn't seem to support the inheritance schemes (a requirement in my case) (2) it's really inconvenient when the class representing the component is accessible from several other classes. based on my understanding, you're only option is to provide the complete component mapping in each of the class mappings that want to use it. that can be a lot of duplication depending on the scenario (and it is in mine) On Tue, Aug 4, 2009 at 8:38 AM, John Rayner <[email protected]<mailto:[email protected]>> wrote: I always thought that <component> mapping was a good way to get the behaviour of a DDD value object (although my DDD knowledge is pretty slim). Have you looked into that? Cheers, John On Aug 3, 4:20 am, Everett Muniz <[email protected]<mailto:[email protected]>> wrote: > I can definitely second the sentiment that there seems to be a gap in the > DDD information readily available when it comes to the nuts and bolts of > applying DDD with the specific technologies that I'm working with (MS stack > at the moment). It may be different in the Java space or in other > language/tech spaces. > I really see the value in the DDD concepts but it can be a pretty daunting > challenge to figure out how to apply the principles well. Particularly, how > to navigate the various trade-off decisions. Sometimes a particular > compromise is just a pragmatic approach to dealing with some technical > limitation and sometimes it's a breech of the conceptual approach that will > hurt you in the long run. Knowing which is which seems to be largely a > matter of experience. It feels a bit like a 'chicken-or the-egg' scenario. > > Outside the kind of mentoring Bob > Martin<http://blog.objectmentor.com/articles/category/uncle-bobs-blatherings> > seems > to be > advocating<http://blog.objectmentor.com/articles/2009/04/01/master-craftsman-teams>it > can be a really painful road for us folks who are trying to find our > way. > > > > On Sun, Aug 2, 2009 at 3:17 PM, Nexus > <[email protected]<mailto:[email protected]>> wrote: > > > Hi > > > In my humble opinion, it should not be a breach of the DDD concept to > > have the id in the valueobject, it is just there for database > > concerns, i has no other meaning. > > > It should also be included out of your equals etc, because only the > > values of the valueobject matter (but i am sure that was allready > > clear to all) > > > I've read many articles, book etc about DDD, none of them go to the > > practical side of DDD, it's all only conceptual :) > > > Hide the id in your class diagram, if it is a value object, and you > > still don't have cruft in your valueobjects, Maybe implement the > > property for the id explicit trough an interface > > > Greetings > > > On Aug 2, 1:26 pm, Fabio Maulo > > <[email protected]<mailto:[email protected]>> wrote: > > > for column name NH is using a convention; in the example of the link the > > > column name is "id".Btw, if you need, you can use the schema to know > > which > > > are the others options (column is one). > > > > 2009/8/2 Everett Muniz > > > <[email protected]<mailto:[email protected]>> > > > > > Right, but in the following example taken from your blog (here: > > > >http://fabiomaulo.blogspot.com/2009/05/nhibernate-versioning.html) the > > > > <id> tag has no property name, no column attribute and no <column> tag. > > > > <class name="Sample"> > > > > > <id type="int"> > > > > > <generator class="hilo"/> > > > > > </id > > > > > <version name="Version" access="backfield"/> > > > > > <property name="Description"/> > > > > > </class> > > > > > Is NHibernate ignoring the id or is it inferring a column name or is > > > > something else going on? > > > > > On Sun, Aug 2, 2009 at 12:42 AM, Fabio Maulo > > > > <[email protected]<mailto:[email protected]>> > > wrote: > > > > >> by default the column name is the property name.You can specify the > > > >> column name adding 'column' attribute or <column> tag. > > > > >> 2009/8/1 Everett Muniz > > > >> <[email protected]<mailto:[email protected]>> > > > > >> 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]<mailto:[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]<mailto:[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]<mailto:[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-wellknowinst...>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]<mailto:[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]<mailto:[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 > > > > >> -- > > > >> Fabio Maulo > > > > -- > > > Fabio Maulo- Hide quoted text - > > > > - Show quoted text -- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
