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 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. 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? -- Hector On Fri, Aug 28, 2009 at 3:32 PM, Tim Navrotskyy <dmytro.navrots...@gmail.com > wrote: > > Hi, > > > Hector Virgen wrote: > > > > The example in the Zend Framework Quick Start [1] involves only a single > > model and a single mapper, which is fine -- the pattern works beautifully > > in > > isolation. But in my application I have many models each with their own > > mappers, and the models are related to each in one-to-one, one-to-many, > > and > > many-to-many relationships. > > > > I think the data mapper pattern is not implemented right in the QuickStart > guide which leads to series of questions like yours. Even on the > http://martinfowler.com/eaaCatalog/dataMapper.html reference page we see: > > > > A layer of Mappers (473) that moves data between objects and a database > > while keeping them independent of each other and the mapper itself. > > > > According to this statement the class Quiz may not depend on any Data > Mapper, including the QuestionMapper. > > The client code (e.g. action controller) using a Data Mapper may look like > this: > > //fetching questions for some quiz > $questions = $questionMapper->findByQuiz($quiz); > > $questions is now a collection of objects with complete question informaton > including the answer choices. > > The client doesn't ask the Quiz Entity to get the questions, but the > mapper. > The question mapper may communicate with the AnswerChoice mapper to fetch > the choices and populate the questions with them. > > Implementing it this way you make your Model independent of the Mapper and > therefore the storage type. > > > Hector Virgen wrote: > > > > Also, since each question belongs to a quiz, should the Question object > > contain an instance of the Quiz object it belongs to? > > > > I think it's acceptable if you use this backreference somewhere. > > > Hector Virgen wrote: > > > > If I follow this pattern, then when I "find" a single AnswerChoice > object, > > the AnswerChoiceMapper would load the parent Question object, which loads > > the parent Quiz object, which loads the parent User object, etc. This > > seems > > to be inefficient, especially when iterating through multiple answer > > choices. > > > > With the Data Mapper layer decoupled from your model you may now implement > another mapper for each use case which pulls exactly as many dependencies > as > needed. You could still use techniques you mentioned like Identity Map or > Lazy Loading. Martin Fowler describes them very good in > http://martinfowler.com/books.html#eaa PoEAA . > > Tim. > -- > View this message in context: > http://www.nabble.com/Data-Mappers-and-Relational-Modelling-tp25193848p25198001.html > Sent from the Zend Framework mailing list archive at Nabble.com. > >
