Re: Pagination and sort design in ddd

If 4, how are you using metadata to accomplish this, if the whole collection is being returned?

--- In [email protected], Dan Haywood <dan@...> wrote:
>
> Both 2 (ideally) but also 4, with metadata to indicate the page size.
> 
> 
> 
> On 17 April 2013 14:51, raymond_kolbe <rkolbe@...> wrote:
> 
> >
> >
> >
> >
> > --- In [email protected], "eben_roux" <me@> wrote:
> > >
> > > Hello,
> > >
> > > I subscribe to the school of thought that believes one should not query
> > the domain model.  If an aggregate can provide you with the required data
> > then fine but one should not be fiddling with the domain model to satisfy
> > querying.
> > >
> > > The solution alluded to by yourself and Rickard I believe is the correct
> > one.
> > >
> > > If you want to go for a seperate bounded context that handles
> > pagination/sorting then that is ok too.  If you are so inclined you can
> > represent your sql statements using some query object (having a query
> > object represent a raw sql statement is also fine in some cases).
> > >
> > > You could go as far as having this BC execute the query and store the
> > paginated/sorted results in working set data structures that can simply
> > return a generic structure for presentation purposes.  These would of
> > course expire after some timeout and can then be cleaned out.
> > >
> > > Hope that helps.
> > >
> > > Eben
> > >
> >
> > Hi all,
> >
> > I'm bringing this thread back from the dead in the interest of cataloging
> > the implementation aspects of pagination/sort w/regard to DDD repositories
> > (attempting to not break the UL under certain use-cases).
> >
> > Assuming that pagination is not part of the UL, but rather an aspect of
> > performance/view concern, I understand the following implementation
> > solutions to exist (including, but not limited to):
> >
> > 1) Return a *Query Object* and allow the client to add additional
> > constraints. I would argue this goes against the UL for a BC and I would
> > urge people to avoid when possible. This is a leaky abstraction into what
> > the repository is responsible for in my opinion.
> >
> > 2) Return a *Lazy Collection* (for a lack of a better term). Essentially
> > this looks and acts like a regular collection but it may choose to defer
> > populating the  collection until the first item in the collection is
> > requested. Alternatively, calling *slice* on the collection would return
> > a specific portion of the collection, possibly returning another *Lazy
> > Collection*.
> >
> > 3) Return a *Paged Result* obj. My understanding is that this would be a
> > fully instantiated collection where *getIterator* returns the current *
> > slice* and *count* returns the total collection sum. E.g. *Paged Result* objs.
> > are a slice of the total collection so no lazy fetching is performed.
> >
> > 4) Return a full *Collection* and rely on caching on the client side.
> >
> > To give some context to how I got here I'll explain the problem I'm
> > working on. I have an aggregate root called *Assignment* which contains
> > an association to an *Employee*, *Topic*, and *Records*. The records
> > provide us information about whether or not the employee is current with
> > their topic training (*Topic*), and also provide an audit trail of when
> > the topic was taken. Some  information is kept on the *Assignment* such
> > as "required", "last taken on" and "status". Status and last taken on being
> > VOs, telling us whether the employee is "Current", "Expired", or "Unknown".
> >
> > Anyway, the *AssignmentRepository* has a method called
> > getRequiredAssignmentsForTopic($topicId). This is used in the domain by the
> > web application (for viewing) and for a reminder system (for notifying of
> > upcoming expiring topic training). In two use case we ask for all
> > Assignments for $topicId (reminders and exporting to CSV, PDF, whatever),
> > and in a third use case we want paginated results for the web.
> >
> > How do others handle this? I'm aware of other solutions as well but I
> > would like to hear what others think.
> >
> >
> >
>




------------------------------------