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