The markup surrounding data in an xml document / feed is no different than the markup of an html page. This belongs in the view layer. Of course the code that fetches and possibly massages the raw data belongs in the model, but the idea is to be able to use this data for anything, xml feed, html page, etc. The model doesn't and shouldn't care where the data will end up.
Feed specific view <-> light feed specific controller <-> model HTML specific view <-> light html specific controller <-> model (same as above) You might even be able to use some generic controller as well, though I haven't done that myself. I'll let others chime in on that... -mike tramontano -----Original Message----- From: Daniel Latter [mailto:[email protected]] Sent: Friday, December 12, 2008 8:17 PM To: A.J. Brown Cc: [email protected] Subject: Re: [fw-general] Newbie quesiton - How do queries that join multiple tables fit into the model in the MVC Yes, thanks, you are right, but say you were creating a specific XML file from scratch using domdocument for example, that involved creating / appending a lot of elements, and this was wrapped up in the form of a custom class you created, wouldnt you store this in the model? And the use in your controller? On Dec 12, 2008, at 23:24, "A.J. Brown" <[email protected]> wrote: > > Generating XML and Feeds should NOT be done with the model. Those are > representations of the data, and should be done with in the > controller and > view layers. The controller layer should determine which > representation to > use by selecting the correct view, and the view should render the > data. > > -- > A.J. Brown > Zend Certified PHP Engineer > WEB: http://ajbrown.org > > > > > Daniel Latter-2 wrote: >> >> As a very loose, and general rule of of thumb the things that should >> be part of your model would things like generating / creating XML >> feeds , ie the code that does this, processing data you've got from a >> database, ie to prepare the data so your app can more easily use it, >> and generally things like that, basically it's the meat of your >> application, the controllers would then use the model classes. >> >> This is a very general description I've explained but I think it's a >> good starting point. >> >> >> On Dec 11, 2008, at 18:56, Bill Karwin <[email protected]> wrote: >> >>> >>> On Dec 11, 2008, at 9:48 AM, Julian102 wrote: >>> >>>> Can anyone explain to me or show me somewhere that explains on a >>>> very high >>>> level for a beginner how the model fits into a system and how one >>>> should >>>> think about it when designing an application. >>>> >>>> For example should the model be designed at the same time the >>>> database is >>>> designed? >>> >>> Not necessarily -- you design the Models as part of your object- >>> oriented design for the application. The database design is for >>> persistence; it doesn't always map directly to your OO >>> architecture. As you've noticed, you could have a Model that uses >>> multiple tables, and you might also use a given table in multiple >>> Models. >>> >>> The Controller and the View have pretty specific roles in an MVC >>> app, related to managing input and producing output respectively. >>> The Model should be where everything else about your app is coded, >>> and the database access is purely an internal implementation matter. >>> >>> Think of it this way: suppose you're in a team and you're >>> responsible for coding the Model, but you're not going to be the one >>> coding the other parts of the app. You need to publish your Model's >>> interface to the other members of the team, and they'll call into it >>> to fetch and save information managed by that Model. >>> >>> The problem is, you know from working with this team that they are >>> untrustworthy bunglers (you suspect they are actually a troop of >>> over-caffeinated chimpanzees banging on keyboards). You're sure >>> that they will abuse a Table's createRow() and update() and delete() >>> methods, messing up data integrity if they are given the chance. >>> They'll call fetchAll() with improper and inefficient queries. And >>> we won't even contemplate what they could do with getAdapter(). >>> >>> So you can't trust them to use a Table class directly. You need to >>> make a Model class, that encapsulates the high-level things your >>> Model can do, exposing _only_ those as task-oriented methods. >>> Methods such as "createNewPost()" and "replyToPost()" and >>> "countPostsInThread()" and "reportAbusivePost()." You can use the >>> Model class to make sure these high-level tasks are done correctly, >>> no matter how incompetent the person who's using your interface is. >>> The Model should encapsulate all the code and all the data needed to >>> accomplish the work for a related set of tasks in your app. Details >>> of how data is stored in the database and how to query it should be >>> known only to you. >>> >>> A few other resources: >>> >>> Esteemed ZF contributor Pádraic Brady posted a great blog articl >>> e re >>> cently called "The M in MVC: Why Models are Misunderstood and Unappr >>> eciated." >>> >>> A free online resource is S. Lott's book, "Building Skills in OO >>> Design." >>> >>> Craig Larman's book "Applying UML & Patterns: Introduction to >>> Object- >>> Oriented Analysis & Design, & Iterative Development" talks about >>> "assignment of responsibilities" which helps you decide what code >>> goes in what class. That's a good in-depth resource to read more >>> about the process of OO design. >>> >>> Regards, >>> Bill Karwin >> >> > > > ----- > Regards, > > A.J. Brown > Zend Certified PHP Engineer > http://ajbrown.me > -- > View this message in context: > http://www.nabble.com/Newbie-quesiton---How-do-queries-that-join-multiple-tables-fit-into-the-model-in-the-MVC-tp20919944p20985372.html > Sent from the Zend Framework mailing list archive at Nabble.com. >
