> if entity is PurchaseOrderLine > Update Purchase Order i don't think it can be based on type. CompletedPurchaseOrder and InProcessPurchaseOrder can both have PurchaseOrderLineItems.
> IMHO, since we are going to live with this fact there's no need to achieve > it all, and may be the solution is business specific. So keeping it with the > events, and a simple Event Aggregator is a more elegant solution I can think > of. Yes... and i like that this makes it explciit what is happening in our code. We could also make everything go through the aggregate root to insure that we update a version number (yuck). i would prefer however to allow a bit more flexibility in how we model this and have the ability to do it transparently (rightly or wrongly). cheers, Greg On Mon, Apr 27, 2009 at 11:30 AM, Sidar Ok <sida...@gmail.com> wrote: >>> As I go > through this though I keep hearing "too much magic" being whispered in > my ear. > > and > >>> with AOP the problem is finding the root (it might be 5 levels deep) > > If you find the root, without knowing about the inverse relationship, that's > gonna be magic in any framework. So to prevent it, I was thinking to KISS > and code directly there > > if entity is OrderLine > Update Order > > if entity is PurchaseOrderLine > Update Purchase Order > > ... > > And so on (or come up with a sort of specification to centralize this logic, > or configuration etc, but that's beyond the discussion.) That's still yucky, > but at least not magic any more. > > This was the main reason why I was saying: > >>> If you see this as a business decision, and don't want to put it in AOP, > > :) > > IMHO, since we are going to live with this fact there's no need to achieve > it all, and may be the solution is business specific. So keeping it with the > events, and a simple Event Aggregator is a more elegant solution I can think > of. > > On Mon, Apr 27, 2009 at 5:23 PM, Greg Young <gregoryyou...@gmail.com> wrote: >> >> Those are all possibilities ... >> >> with AOP the problem is finding the root (it might be 5 levels deep). >> I was looking at Peter's suggestion but don't like what it requires. I >> am currently looking at a way to do this only in proxies but the trick >> is in finding out what aggregate root we are under while not having >> the id carried by the domain objects ... One thing I see is having the >> IHaveParentId be implemented by the proxy ... then have an >> IAggregateRoot for the actual parent ... so you can just keep walking >> up the path but none fo the objects carry the ids themselves. As I go >> through this though I keep hearing "too much magic" being whispered in >> my ear. >> >> Greg >> >> On Mon, Apr 27, 2009 at 11:17 AM, Sidar Ok <sida...@gmail.com> wrote: >> > Isn't this a good candidate for AOP ? So when a child entity's version >> > is >> > updated, whether by NH or externally, you go and update the aggregate >> > root(s) too. >> > >> > If you see this as a business decision, and don't want to put it in AOP, >> > may >> > be an event driven solution would do ? Child publishes >> > HeyIHaveBeenUpdated >> > event and have aggregates subscribe to it. >> > >> > Am I thinking too simple and missing something ? >> > >> > On Mon, Apr 27, 2009 at 4:51 PM, Greg Young <gregoryyou...@gmail.com> >> > wrote: >> >> >> >> Yeah that's about what I thought ... it gets ugly also when you start >> >> going n levels deep and end up having to walk bunches of >> >> bi-directional relationships. This is something that really needs to >> >> be a first class concept to work without being too complex. >> >> >> >> I was hoping some people had some brilliant solution that had just >> >> alluded >> >> me :( >> >> >> >> makes me curious though how exactly so many people are doing "DDD" >> >> with nhibernate? I am suspecting more and more that these people are >> >> in fact not doing DDD at all but instead are doing "DDD as a pattern >> >> language". you can force everything through the aggregate and touch >> >> its version but yuck! >> >> >> >> Cheers, >> >> >> >> Greg >> >> >> >> On Fri, Apr 24, 2009 at 4:00 AM, Peter Morris <mrpmor...@gmail.com> >> >> wrote: >> >> > >> >> >> >> >> > I see what you are saying .... build an interceptor ... then make my >> >> > root traversable from all thechildren .. have interceptor make the >> >> > session.Update call .. Is that correct? >> >> > < >> >> > >> >> > It's the way I have done it in ECO (capableobjects), I make each part >> >> > implement IAggregatePart which has a GetRootObject I can call to >> >> > ensure >> >> > the >> >> > root is updated too. >> >> > >> >> > If you are using Created/Modified etc on a Repository rather than >> >> > using >> >> > it >> >> > only as a query mechanism then the repository can do that for you, >> >> > because >> >> > the only way to call Update to save the child is to go via that >> >> > Repository. >> >> > >> >> > >> >> > Pete >> >> > ==== >> >> > http://mrpmorris.blogspot.com >> >> > http://www.AlterEgos.com - Who do you want to be? >> >> > >> >> > >> >> > > >> >> > >> >> >> >> >> >> >> >> -- >> >> It is the mark of an educated mind to be able to entertain a thought >> >> without accepting it. >> >> >> >> >> > >> > >> > >> > -- >> > Sidar Ok >> > >> > http://www.sidarok.com >> > http://www.twitter.com/sidarok >> > >> > >> > > >> > >> >> >> >> -- >> It is the mark of an educated mind to be able to entertain a thought >> without accepting it. >> >> > > > > -- > Sidar Ok > > http://www.sidarok.com > http://www.twitter.com/sidarok > > > > > -- It is the mark of an educated mind to be able to entertain a thought without accepting it. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to nhusers@googlegroups.com To unsubscribe from this group, send email to nhusers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
