Zend FR

deux cas se présente
soit la partie de modèle que gêre le module est propre au module et le le place dans le dossier model du module
soit cette partie de modèle est utilisé ailleur dans l'application et je le place dans le dossier model de l'application.

A+JYT

mikaelkael => Au cas où quoi?

Personnelement, voici ce que j'ai par exemple dans le fichiers application\models\News.php

<?php

class News extends Zend_Db_Table
{
    protected $_name = 'tb_news';
}

Ensuite dans mon controller je mets dans la fonction init => Zend_Loader::loadClass('News');

Je peux ainsi appeler depuis toutes les actions de mon controller la table news de cette façon : $news = new News();

Est-ce aussi simple que cela? Je fais la même chose pour toutes les autres tables? Y-a-t-il moyen d'optimiser cela ?

En gros, comment gérer la couche model ? (Avec un petit exemple )

Hello,

Au cas où j'en aurais besoin plus tard dans un autre module. Chacun de mes modules correspond en gros à une base de données. Chaque module correspond en fait à une application à part entière. C'est d'ailleurs comme cela que j'ai travaillé au début (plusieurs petites applications). Puis avec l'évolution des demandes (recherches croisées), j'ai tout fusionné sous une application. Mes models sont donc positionnés dans /application/models. Chaque module pouvant ainsi interroger toutes les bases.

Mon organisation est la suivante :
- application
  -models
   -base1
    -tablex
   -base2
    -tabley...

Les class de tables sont de la forme :

<?php

class Base2_Tabley extends Zend_Db_Table
{}

Dans n'importe quelle action de n'importe quel module, je peux faire :

$retour = $this->base2db->table_tabley->fetchAll();

base2db est trappée dans le __get() du controller qui reconnait une base et charge l'adaptateur en conséquence. table_tabley est trappée dans le __get() de l'adaptateur qui reconnait une table et la charge.

Ainsi mon script ne charge que la(es) base(s) et les tables nécessaires.

A+

moi j'écris

        $this->model->addComponent('Adm_Model_Profile');
        $profiles = $this->model->getProfileList($formData->usr_id);

Hello,

Je vois que le principe est le même pour tout le monde. Les méthodes sont simplement différentes.

Ainsi mon script ne charge que la(es) base(s) et les tables nécessaires.

Pourquoi chargé un adaptateur, un model ou une table dans un init si ce n'est pas pour l'utiliser ensuite ?
Exemple : ma page d'accueil est ma page de login sans aucun besoin d'accès à une base. Certaines de mes pages sont stockées en cache donc pas besoin d'accès à une base.

Ma principale application est un infocentre qui n'est pas du tout de type CRUD. Je ne fais quasiment que du select. Mes contrôleurs ne sont donc pas désignés du style : createAction, updateAction... Dans ce cas, il est vrai que tu peux passer par l'init puisque toutes tes actions vont avoir besoin de la table.

Cet infocentre se connecte à 12 BDD différentes en fonction de la requête (9 Oracle, 1 MSSQL & 2MySQL). Je ne m'amuse donc pas à charger les 12 adaptateurs par défaut. Ils sont chargés automatiquement si la requête en a besoin.

Cela répond-il à ta question ?

A+

Hello,

Ceci est une instanciation d'objet (pas de classe) :

$news = new News();

Ceci est un chargement (=load en anglais) de classe :

Zend_Loader::loadClass('News');  // Le but de ce code est de remplacer include/require

C'est 2 portions de codes sont explicites. Tu as besoin de les appeler pour que ton code fonctionne. La différence avec moi, c'est que je ne les appelle jamais : c'est ce que j'appelle le chargement automatique.

D'après ce que tu écris, tu as au moins 2 bases (news & photos). Quand tu es dans le module news, tu n'as besoin que de la base news. Dans ce cas, c'est vrai que le chargement et l'instanciation explicite sont plus communs. Dans mon cas chacun des 15 modules peut appeler une (ou plus) des 12 bases. Je ne souhaitais donc pas charger explicitement tous les objets.

J'utilise le __get() de PHP :

class Extension_Controller_Action
{
    public function __get($name)
    {
        if (substr($name,-2)=='db') {
            $this->{$name} = Fonctions::ChargerBase($name);  //ChargerBase fait en gros le chargement de la classe et l'instanciation de l'objet
            return $this->{$name};
        }
    }
}

Et tous mes contrôleurs étendent Extension_Controller_Action :

class MonController extends Extension_Controller_Action
{}

Même chose pour mes tables mais le __get() est dans mon model.

A+

Dernière modification par mikaelkael (21-05-2008 09:27:30)

mikaelkael a écrit:

Hello,

Je vois que le principe est le même pour tout le monde. Les méthodes sont simplement différentes.

Ainsi mon script ne charge que la(es) base(s) et les tables nécessaires.

Pourquoi chargé un adaptateur, un model ou une table dans un init si ce n'est pas pour l'utiliser ensuite ?
A+

c'est justement ce que je fait avec ma façade (l'objet $model)
de dans cet objet je ne place aucun adaptateur aucune table je place juste des méthodes correspondant à une action métier par exemple Calculer Facture
ces méthodes ne porte pas le code métier. mais sélectionne dans la couche métier l'adaptateur, la table, la classe capable de répondre à cette demande.
je regroupe ces méthodes de façon logique (métier) en classes appelée composants

mon contrôleur charge les composants qu'il est susceptible d'utiliser (soit dans le init s'il l'utilise dans toutes les action, doit dans l'action elle-même) à ce moment là aucune table aucun adaptateur aucun code métier n'est chargé.

seul les classe nécessaire à la méthode invoqué sera chargé au premier appel de celui-ci.
dans l'exemple

        $this->model->addComponent('Adm_Model_Profile');
        $profiles = $this->model->getProfileList($formData->usr_id);

la première ligne permet simplement d'attacher la méthode getProfileList à l'objet model (et quelques autre méthode du composant) aucune classe métier n'est chargée.

à l'invocation de la deuxième ligne le composant va chercher l'objet capable de fournir le service.
s'il s'agit d'un annuaire LDap alors la classe d'accès LDap sera charge s'il s'agit d'une base alors ce sera un adaptateur, etc. bref ce n'est qu'à ce moment là que les classes se charges.

si le contrôleur utilise une autre méthode du model seule les classes manquante seront chargée.

donc au pire si un composant est chargé ce n'est que la définition que quelque méthodes qui ne font aucun traitement qui sont définie, et aucune classes n'est chargée

A+JYT

Donc d'après ce que vous dites (et en particulier mikaelkael), tu ne charges qu'une seule classe qui se trouve dans le fichier models.php du répertoire application/models dont le contenu est le suivant:

class Extension_Controller_Action
{
    public function __get($name)
    {
        if (substr($name,-2)=='db') {
            $this->{$name} = Fonctions::ChargerBase($name);  //ChargerBase fait en gros le chargement de la classe et l'instanciation de l'objet
            return $this->{$name};
        }
    }
}

Cette classe te permet de charger les bases à la volé. (j'espere que je n'ai pas faux jusque là)

Mes questions sont :

Concrétement, quel est le principe du __get() ? Si je comprend bien, c'est une sorte de détection d'appel de fonction finissant par "db". Comment ceci est mit en place? Il suffit de charger la classe model.php qui contient le code ci-dessus?
Où se trouve ta fonction ChargerBase ?

Est-ce que je perds vraiment en performance de charger toutes mes bases ? (une quarantaine de bases (mysql))

Est-ce que l'architecture que je vous ai présenté dans mon post précédent vous semble correcte?

Ca fait beaucoup de question et je vous remercie de votre aide.

Dernière modification par slaughter (21-05-2008 23:25:17)

Tout me semble beaucoup plus clair maintenant. Je testerai ça ce soir (j'aurais surment d'autres questions à venir). Sans vouloir trop abuser, serait-il possible d'avoir un aperçu de ta fonction ChargerBase ? =p

Bon, je vais encore passer pour l'interminable débuttant.

Actuellement j'ai un répertoire [models] contenant tous mes models. Dans un controlleur, si j'ai besoin d'un model je fais dans le init() $this->table = new Table(); ou bien dés que j'ai besoin d'une table dans une action. De ce fait, je charge que la table en question non ? J'ai du mal à comprendre : si j'ai une seule base, ma méthode de travail reste standard ou à un moment donné je devrais penser à travailler comme vous ?

Si j'ai bien compris ce code

class Extension_Controller_Action extends Zend_Controller_Action
{
    public function __get($name)
    {
        if (substr($name,-2)=='db') {
            $this->{$name} = Fonctions::ChargerBase($name);  //ChargerBase fait en gros le chargement de la classe et l'instanciation de l'objet
            return $this->{$name};
        }
    }
}

ça te permet 'simplement' à choisir le bon adapteur ? Ce que je ne comprends pas dans cette ligne :

$this->view->liste = $this->base1db->table_toto->fetchAll();

c'est à quoi correspond 'base1' ? Comment tu fais pour sélectionner une table précise, ici table_toto ? C'est bien dans ChargeBase() que tu sélectionne ton adaptateur et la table ? Ce serait à se moment que tu initialises la table_tot avec la $db correspondante ?

Hello,

Il faut reprendre mes premiers messages.

base1db est trappée dans le __get() du controller qui reconnait une base et charge l'adaptateur en conséquence. table_toto est trappée dans le __get() de l'adaptateur qui reconnait une table et la charge.

Je n'ai montré que le __get() du contrôleur mais il y en a un autre dans base1.php pour charger la table toto.

class BaseModel               // situé dans /library/...
{
    /**
     * @var Zend_Db_Adapter_Abstract
     */
    protected $db;

    public function __construct()
    {
        //instanciation de $this->db
    }

    /**
     * Ajoute une table en tant que membre public
     *
     * @param string $nom
     * @param array $config
     */
    public function ajouteTable ($nom, $config = array())
    {
        $configdb = $this->db->getConfig();
        $dbname = str_replace('_test', '', $configdb['dbname']);
        $nom = str_replace(' ', '_', ucwords(str_replace('_', ' ', $nom)));
        $classe = ucfirst($dbname) . '_' . $nom;
        $nom_dans_classe = 'table_' . strtolower($nom);
        if (! isset($config['schema'])) {
            if ($this->db instanceof Zend_Db_Adapter_Oracle) {
                $config['schema'] = $configdb['username'];
            } else {
                $config['schema'] = $configdb['dbname'];
            }
        }
        if (! isset($config['name'])) {
            $config['name'] = $nom;
        }
        $config['db'] = $this->db;
        $this->$nom_dans_classe = new $classe($config);

    }

    public function __get ($name)
    {
        if (substr($name, 0, 6) == 'table_') {
            if (isset($this->$name)) {
                return $this->$name;
            } else {
                $this->ajouteTable(substr($name, 6));
                return $this->$name;
            }
        }
    }
}

class Base1 extends BaseModel  // situé dans /application/models/base1.php
{}

Le fichier model.php contenant les classes des tables étant chargé de toutes façon partout (tous les controllers) et dans tous les cas (de ta façon ou de la manière standard) en faisant

Non c'est justement ce que je ne veux pas. Chacun de mes Base1 ou Base2 ne sera charger que si l'on a appelé.

$toto = new toto();  
$this->view->toto = $toto->fetchAll();

Ceci ne fonctionne que si tu n'as qu'une seule base et que tu as auparavant fait Zend_Db_Table::setDefaultAdapter($tonAdapter). Ce n'est pas mon cas.

Autre point, plus subtil, je vous l'accorde : si j'utilise Zend_Layout et que j'empile des actions (ActionStack), si je fais : $this->base1db->table_toto->fetchAll() ou find(). Base1 et Toto correspondront aux mêmes instances. Dans ton cas, "$toto = new toto();", tu créeras autant d'instances que de new.

A+

Dernière modification par mikaelkael (22-05-2008 16:12:32)

Mais cette fameuse façade... quelle est sa classe ? De quelle classe du ZF hérite-t-elle ?
D'entrée j'ai envie de dire Zend_Controller_Action, étant donné que dans le MVC, ce sont ces classes qui apellent les tables... mais du coup je ne vois pas trop l'intérêt de la façade