Zend FR

Je vais essayer d'éclaircir tes propos, si jamais cela arrive à d'autres (Avec un complément d'informations).

Tu a un include_path qui correspond (normalement/par defaut) à :

set_include_path('.' . PATH_SEPARATOR . '../library' . PATH_SEPARATOR . '../application/models/' . PATH_SEPARATOR . get_include_path());

Dans le dossier "models" qui est dans application, il y a tout mes models.

Ensuite l'autoload fonctionne.

Si jamais, tu classe un peux mieux tes models du style :

->application
   ->models
      ->Form
      ->Dao
         ->News.php

L'autoload ne va pas changer, ni le include_path, mais tes models.

Au lieu d'avoir par exemple pour le model News.php:

class News extends Zend_Db_Table_Abstract{
    protected $_name = 'news';
}

Tu aura :

class Dao_News extends Zend_Db_Table_Abstract{
    protected $_name = 'news';
}

Et quand tu appellera ton model, tu le fera comme ça : $news = new Dao_News();

Je vien juste de comprendre, donc mes informations peuvent être fausse. mais chez moi, cela fonctionne !

Dernière modification par Seazer (30-04-2009 17:27:19)

un peut de lecture sur la séparation de la couche persistance de la couche métier

l'idée générale est que la couche métier ne doit s'occuper que du métier c'est a dire uniquement des fonction que l'on peut faire avec l'objet concerné par exemple le calcul de la tva dans une facture, le calcul de l'age d'un client, la consolidation des comptes de l'entreprise etc. et ceux sans avoir à savoir ni où ni comment les données concernée sont enregistrées ni utilisé. cette phase s'appelle la modélisation métier. elle est en mettre en regard de comment le métier sera utiliser dans l'application ne serait-ce que pour savoir si le métier est capable de répondre au besoin de l'usage qui en sera fait. la modélisation de cet usage du métier permet de définir les contrôleurs.

d'un tout autre côte se pose la question se savoir comment on va garder les donnée. cela passe par la modélisation des données que ce soit dans une basse de données un fichier un annuaire LDAP ou tout autre support. bien évidement la modélisation des données doit tenir compte des contrainte d'exploitation et d'usage de celle-ci. si on a des données très hiérarchique sur le quel on fait beaucoup d'accès en lecture et peu en écriture un annuaire AD ou LDAP ou autre est un bon support si à l'opposé les données ne sont pas hiérarchique et nécessite beaucoup d'accès en écriture une base sera plus adaptée. au final suivant le support et donc toute les contraintes le modèle de donnée sera différent.

reste à faire le lien entre les objets métier définis dans la modélisation métier et les structures de données définies par la modélisation des données. cette partie s'appelle la persistance c'est elle qui va définir ce qui doit passer du métier ver la structure de donnée et vice versa et comment cela doit se faire.

voici donc quelques liens qui traite de ce sujet (pas nécessairement en php)
http://blog.developpez.com/index.php?bl … des_couche
http://www.dotnetguru.org/articles/Pers … apping.htm
http://www.bodysplash.fr/index.php?post … nd-melange
http://www.jmdoudoux.fr/java/dej/chap038.htm
http://fr.wikipedia.org/wiki/Architecture_trois_tiers
http://fr.wikipedia.org/wiki/NHibernate
http://docs.jboss.org/hibernate/stable/ … e/fr/html/

si on rapporte ça à ZF les classes dérivées de Zend_Db_Table et Zend_Db_Table_Row sont les objets destinés à faire l'accès aux données (en base) comme dans tout langage on peu les utiliser directement mais ont peut aussi définir ses propre classes métiers qui vont utiliser ces classes d'accès aux données et donc mettre en place une persistance au travers de ses classes.

A+JYT