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
recently called "The M in MVC: Why Models are Misunderstood and
Unappreciated."
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