On 13 May 2013 14:44, GESCONSULTOR - Óscar Bou <[email protected]>wrote:
> > There seems to be a "little" debate about "referencing ids vs lazy loading > (with or without "direct" reference)" and more on the DDD Yahoo User > group... > > http://tech.groups.yahoo.com/group/domaindrivendesign/message/24048 > > You know, after 5 years on that list I've now unsubscribed. To my mind most conversations get bogged down in technical implementation details (this thread is a good example). > The main point is that sometimes this "Domain Id." does not correspond to > any Domain concept, so it shouldn't be introduced on the Domain model. > > Indeed. Except you have to do that if using (what the blog post you reference below calls) the "aggregate documents" pattern. > > Also, there's an interesting blog post about this 2 ways of implementing > DDD: > > http://rogeralsing.com/2009/11/08/two-flavors-of-ddd/ > > I remember reading this blog post a while back; yes, it's a good one. Though the main reason to not use "aggregate graph" (ie ORMs) is: they are hard to use. You know: I think that's right in the general case. The way that Isis uses an ORM is more naturally constrained by the framework; because the interactions are generic, if we fix an N+1 issue in one place, we tend to fix it anywhere. All this does though is move the argument: ORMs aren't necessarily tricky if using an NO-style framework. "Ah yes, but NO can't possible work" is usually the rebuttal. > > But I simply would notice that both approaches can be mixed (specially on > different Bounded Contexts). If one BC is implemented over a framework that > supports by default "lazy loading" a direct reference will be exactly the > same in size as a "referencing id" and none of the problems noticed on > Vaughn's "Implementing DDD" would occurred. > > Agreed. IDs are needed for wiring different BCs together. And tend not to be needed (unless they are part of the UL) within a BC, if an ORM is in use. ~~~~~~~~~~ > > During my evaluation, I think the following assumptions can be made about > the Apache Isis default programming model (please, correct me if any of > them is incorrect or if there are any additional points to consider): > > - By default all referenced objects are lazy-loaded. > Yes, because that is JDO/DN's default. However, you can influence this using fetch groups.[1]. At the moment Isis only ever uses the default fetch group. I could imagine in the future that we might define a set of named fetch groups for certain interactions, and thus allow the domain programmer to influence what's going on. But right now, it's just the default fetch group that is used. > - Wicket viewer only implicitly loads a referenced object for showing it's > name. For the referenced object only it's name will be loaded, so this will > break the "loading chain" (no other referenced objects, are they will also > be lazy-loaded, unless explicitely told; nor the name of this dependent > objects). > More precisely, its title. As you know, the title is computed via the title() method or using the @Title annotation, so Isis will load (or cause to load) as much of the object as is necessary. One trick you can do, if the title is expensive to compute, is to have a @Hidden property which holds the title, and update it whenever underlying information changes. You could do this in the updating() callback, for example. We've done this once or twice. > - Updating collections will not cause JDO/DataNucleus to update the > version on the Aggregate Root / PersistenceCapable Entity. > That is true. I don't know of any way to change that. > - Collections are "disabled" (lazy-loaded) by default, unless explicitely > annotated, by the Apache Isis "contract" with the programmers and > implemented viewers. Yes, though again you can use JDO/DN fetch group may override this. > If they must be eagerly loaded, the programmer must explicit it by > annotating the Collection with @Resolve(Type.EAGERLY), such as in: > > public class Order { > @Resolve(Type.EAGERLY) > public List<LineItem> getLines() { ... } > ... > } > > This is a hint to Isis rather than JDO. If you haven't used a fetch group then underneath you will most likely see two queries: one for the Order object, and another for the LineItems. It shouldn't be an N+1 query, though. > - Same happens for direct Entity references: > > public class Order { > @Resolve(Type.EAGERLY) > private Customer customer; > ... > } > > This is redundant; we always render the title of 1:1 referenced objects, so this does nothing. Again, under the covers there will likely be an additional query to fetch that referenced (customer) object in order to render its title. HTH Dan > > > Cheers, > > Oscar > > [1] http://www.datanucleus.org/products/datanucleus/jdo/fetchgroup.html
