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 <b...@karwin.com> 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 article 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
