2009/8/29 Hector Virgen <[email protected]>
> Thanks for the reply, Tim. So you're saying I'll need one or more mappers
> for my Quiz entity depending on how much information I want to prefill the
> quiz with? For example I'll have classes like:
>
> - QuizSimpleMapper
> - QuizWithQuestionsMapper
>
> Let's say we allow the users to tag their quizzes from a set of global
> tags, and they can use as many tags as they want. Would I then need more
> mappers?
>
> - QuizWithTagsMapper
> - TagMapper
> - TagWithQuizzesMapper
>
> Then, if I need a Quiz with its questions and its tags, do I need to create
> yet another mapper?
>
> - QuizWithQuestionsAndTagMapper
>
> I think you could implement the quiz mapper variations in the finder
methods if you don't have much logic in them.
$quizCollection = $quizMapper->findWithQuestionsByUser($user);
Or even:
$quizCollection = $quizMapper->findQuestionsByUser($user, array('questions',
'tags'));
giving the denepndencies in the array as arguments.
> This is becoming overwhelming. I feel like this complexity could be
> simplified if the entity had access to the mapper that created it, allowing
> it to pull in more data in a lazy-loading fashion. But as you said, that
> goes against the design pattern.
>
You could achieve this by using the Separated
Inteface<http://martinfowler.com/eaaCatalog/separatedInterface.html>Pattern
as suggestend in PoEAA, so the entities don't depend on the
datamapper, but just on the interfaces. Lazy
Loading<http://martinfowler.com/eaaCatalog/lazyLoad.html>is great but
it also brings a lot of complexity with it. I decided to use
the preloading of the entities in the mappers for almost all use cases
because it was simpler at the end.
> What I have been working on lately has been an "entity collection" object
> which contains a mapper instance and a list of IDs. It implements the
> SeekableIterator and Countable interfaces and uses lazy-loading to load the
> actual entity on demand when My_Model_Entity_Collection::current() is
> called. This seems to help so that objects aren't created until they're
> accessed, and they can be accessed without any additional work on the
> object. Any thoughts on this?
>
You will get in a problem which is called ripple loading in an iteration.
My_Model_Entity_Collection::current() will issue a SQL query for every
entity. Also, what I don't understand is how the list of ID's gets into
collection.