Hi,
Keith Pope wrote:
> So now for highly specialized queries I would have them inside the
> repository, not sure about
> fetchBlueArticlesOrderedByGermanyPaidLastMonth() but I would have a
> pretty descriptive method name :) I have implemented a criteria object
> so the rules can be easily added at runtime, so maybe something like
> getOrderedArticlesForMonth(). Using the repo you can then do something
> like:
>
> $articleOrderRepo = new Kp_Model_Repository_ArticleOrders();
> $articleOrderRepo->addCriteria(new
> Kp_Domain_Repository_Criteria('color', '= ?', 'blue'));
> $articleOrderRepo->addCriteria(new
> Kp_Domain_Repository_Criteria('country', '= ?', 'Germany'));
> $articleOrderRepo->getOrderedArticlesForMonth(10);
>
> The only thing here is that the criteria/repository are fairly one
> dimensional so complex joins would need to be placed inside the mapper
> as its hard to accurately generate the correct joins. Also sometimes
> for large queries, for example when doing a export of all order for a
> year, I have a getRaw type method on the repository, this will then
> return data instead of objects to stop memory errors.
You are having a data mapper *and* a repository?
Could you please explain, how your repository communicates with your mapper?
Isn't there a code duplication or overhead when you abstract and translate
the query?
In my understanding using a repository to abstract the query gives you the
ability, to change the data mapper, without the need to change any code in
your service layers. But that would require to abstract the query in the
repository and to translate that abstracted query into a specific query in
the data mapper.
--
Regards,
Thomas
