Hi
I'll show which is my work way.
I create a file for each database table, and inside them, i create some
functions that act as a 'facade'.
(Note: i hate ORM tools, so my aproach is more DAO alike)
So, in example, if i have a "news" table i'll represent it with a
Model_News.php class.
Inside this class, i'll have different methods to provide functionalities
demanded by controllers.
The controllers never should know if they're requesting data against a
database, webservice or a file.
All the final validations must be done in the model layer (the database can
do validations too, using checks, triggers and procedures). We can do extra
validations in the presentation layer (with ajax or something similar) to
improve user experience, but the model ALWAYS must do the validation.
So, if someday the model changes, i've only need to change the model classes
and never the views or the controllers.
Class Model_News {
function getStory($id) {
//database call or open file or webservice call
return array('id'=>$id, 'header' => $header, ....);
}
function insertStory($data) {
// validation for $data
// if everything is ok --> insert data into the database, or
call a webservice....
returns true or false depending on the validation, insertion
procedure...
}
...
}
If a model table needs to be joined to another one, like users with groups,
i'll do the request inside a method.
In example, i want the users lists grouped by usersgroup.
Class Model_Users {
function getUsersByGroup() {
//sql, file, or webservice requesting the data
//if it's sql, i'll do a join between users and groups
// finally, i'll always return an array
}
...
}
So, the controller always get an array of data. The classes can have an
internal error variable, so we can always ask about the last error.
I think returning a PDO recordset from the model classes can be a bad idea,
because we are making a dependency between the model and the controller.
ITOH, maybe could be better to save the array of data inside the class and
offer a fetch method or something like these to iterate through the results.
These are my five cents.
I want to look forward your opinions, suggestions and alternative ways of
work.
P.D. Sorry for my english...
Xavier Vidal Piera
Enginyer Tècnic d'Informàtica de Gestió
Tècnic Especialista en Informàtica de Sistemes
[EMAIL PROTECTED]
610 68 41 78
> -----Mensaje original-----
> De: Simon R Jones [mailto:[EMAIL PROTECTED]
> Enviado el: viernes, 09 de febrero de 2007 17:47
> Para: [email protected]
> Asunto: [fw-general] Basic db model question
>
> hi,
> I wanted to pick your brains on what people consider best
> practise on how to organise SQL queries / database models in
> a ZF application.
>
> The docs note the following folder:
> /application
> /models
>
> Do people create a data model per "database object" to define
> what the representation of the data object is? A data model
> may represent one table (i.e. category) or more likely data
> across multiple tables (i.e. a user with a user group, etc).
>
> Do you include the SQL statements to get, update, etc, the
> data to populate this object in the same data model file - or
> a separate one to keep things tidier?
>
> Any thoughts appreciated,
> Si
>
