Hi Koen, Marry the query to a domain model method (i.e. add it to the Data Mapper), and filter it into domain objects before returning the collection. You'll need a Collection class, just like Zend_Db_*'s rowset classes for the root of the aggregate (User) but it needn't be more than a general Iterator implementation. You can also filter the query inputs (any primary keys) against a local Identity Map to prevent duplicates. This does have a slight disadvantage if the existing entities are not fully loaded as they can spark extra queries to load the reference entities through lazy loading.
The filter logic, is really just another form of mapping logic. I know I use a simplistic use case but the principles remain the same - you just need a more specific set of operations in a Mapper to make the JOIN translate across to the domain model. Ensuring the returned results are easy to pick apart by entity is the only requirement needed for the query. So no, you do not need Doctrine to do this. ;). Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com OpenID Europe Foundation Irish Representative ________________________________ From: Koen <[email protected]> To: Pádraic Brady <[email protected]> Cc: Zend Framework General <[email protected]> Sent: Friday, August 21, 2009 2:51:32 PM Subject: Re: [fw-general] Question regarding models Hi Pádraic, Thanks for mentioning the URL, it's very interesting! Still I have some questions left. As an example lets say I want to list 50 users. Every user has several linked fields in another table, like department, company, etc. If doing this the aggregated way, you will end up having it least 150 queries, while this can be done using 1 (!) query with a few joins. Here's a quote from the URL you gave: "Database operations are expensive, often the most expensive operation" So with this in mind, its hard for me to use the 150+ queries solution, although I see some big advantages. I know you can cache, but still... Isn't there some 'in between' solution? Regards, Koen 2009/8/21 Pádraic Brady <[email protected]> Hi Koen, > >I just published a chapter on implementing the Model you may want to look into >to see how it fits. The book is free to read ;). >http://www.survivethedeepend.com/zendframeworkbook/en/1.0/implementing.the.domain.model.entries.and.authors > >I think the main point I think is that you are thinking in terms of the >database. Why use a join? You can use two distinct SQL queries and then >aggregate these as objects. In the book, I used a simple example of blog >entries needing authors - so the entry object contains an author object. > >Joins are great, no mistake, but they are also premature optimisation. You can >offset the cost of two queries using caching and > lazy loading to avoid database access in the first place. > >Hope this helps! > > Pádraic Brady > >http://blog.astrumfutura.com >http://www.survivethedeepend.com >OpenID Europe Foundation Irish Representative > > > > > > ________________________________ From: Koen <[email protected]> >To: [email protected] >Sent: Friday, August 21, 2009 11:36:35 AM >Subject: [fw-general] Question regarding models > > >>I've been looking at the new Quick Start in the ZF manual, particularly the >>model part. For a new project I'm trying to create my models in the same way >>(including a data mapper, etc). > >Unfortunately I don't know how to handle the relationships. When requesting >data from your model you often want to include some fields in related tables >(using joins), but I don't see a way doing that using the pattern as described >in the quick start guide. Can someone give me some tips regarding this? > >Thanks in advance! >
