Zend FR

Tout est relatif. Clairment oui c'est se compliquer un peu plus au départ mais il faut voir à long terme, cela permet de ne pas être dépendant de Doctrine :
- au niveau de sa pérennité, si demain le projet meurt,
- au niveau de ses bench, si demain Zend ou autre sort un ORM beaucoup plus puissant ou tout simplement que l'on souhaite retravailler avec l'adaptateur natif.
Et si l'une des deux situations arrive alors on aura prévu une maintenance et évolution plus souple, on se sera finalement simplifier le travail.

On peut aussi défendre l'idée que c'est sans fin. Abstraire totalement PHP au niveau le plus bas, simpleXML, PDO & Co, faire des sur-couches sur les composants de Zend_ pendant qu'on y est ? C'est vrai on ne sait jamais ce que va devenir le langage.
Faut peser le pour et le contre.

J'attends le retour de Delprog pour savoir si j'utilise des DAO persos ou pas.

Il faut aussi avouer qu'il y a une grande part de fun, d'auto-satisfaction à coder toujours plus loin
J'ai beaucoup appris en 2/3 jours avec ce topic grâce à ceux qui ont participé. Aussi bien sur les concepts que sur la mise en oeuvre.

Dernière modification par dorian53 (23-09-2009 15:05:45)

Le nom d'une propriété ne commence jamais par une majuscule, convention

Donc pour moi c'est "Model_Profil" pour la classe, et "profil" (et non pas Profil) pour la propriété dans un objet "Model_User" qui attend un "Model_Profil". Encore une fois c'est un propriété et pas une classe dont on parle.

Je ne me complique pas la vie, j'applique des concepts qui assure une bonne pérennité de l'application. Ce ne sont pas des choses que j'invente, ce sont des patterns éprouvés et solides.

Tout dépend de la dimension du projet. Ici je parle de projet "lourd".


@Dorian

J'utilise directement le résultat des requêtes qui sont des Doctrine_Record ou des collections. Je n'utilise tout simplement pas des méthodes de ces objets dans mes controlleurs qui n'existeraient pas dans de véritables objets métiers.

L'efficacité des patterns n'est plus à prouver. Il ne s'agit pas seulement de se protéger dans le cas d'un changement de techno, mais aussi, et surtout je dirais, de permettre une bonne maintenabilité de l'application.

Quand il y a une grosse équipe, sur un gros projet, c'est difficile de faire autrement. Si tu fais tout dans les controlleurs, c'est inbuvable.

J'ai moi même des petits projets dans lesquels j'utilise Zend_Db directement dans les controlleurs. Tout dépend de ce que l'on fait

A+ benjamin.

Dernière modification par Delprog (23-09-2009 15:52:43)

Delprog a écrit:

J'utilise directement le résultat des requêtes qui sont des Doctrine_Record ou des collections. Je n'utilise tout simplement pas des méthodes de ces objets dans mes controlleurs qui n'existeraient pas dans de véritables objets métiers.

Delprog a écrit:

Même pas de save ou de link. De même je n'utilise jamais les tables générées par Doctrine directement. J'ai des services (consommé par mes controlleurs) qui passent par des DAO qui eux utilisent ces tables et les fonctionnalités de Doctrine à volonté.

Comme ça, si je change, je ne ré-écris rien dans mes controlleurs ni mes services, seulement mes DAO. A condition que je ré-utilise des objets métiers construits à l'identique bien sûr.

Dis, tu pourrais pas nous montrer quelques petits bouts de code? (Chuis paresseux). Par exemple comment tu save() tes objets métiers. Tu as implémenté un mapper sur les objets de Doctrine? (j'y ai pensé, mais j'hésite).

Merci.
Lesauf

18s pour chargé tes models ?!!! T'as un soucis.. T'es en agressive ou conservative ?

$manager->setAttribute(Doctrine::ATTR_MODEL_LOADING, Doctrine::MODEL_LOADING_CONSERVATIVE);
echo time()."\n";
Doctrine::loadModels($doctrine_opt['models_path']);
echo time(); die();

1253783841
1253783841

booradley a écrit:

Le pb est que le nom des classes générées par Doctrine ne contient aucun préfixe et semble donc incompatible avec la méthode de chargement de Zend.

Regarde plus haut dans le topic la réponse a été donnée.

Doctrine::generateModelsFromYaml('temp.yml', 'models',
    array('classPrefixFiles' => true,
            'classPrefix' => 'Orm_',
            'baseClassPrefix' => 'Entity_',
            'baseClassesDirectory' => 'Entity'));

Je ne pense pas que ca soit Doctrine ou l'autolader du ZF qui changera qqchose.

Car, un include, c'est toujours un include que ca soit avec Doctrine, ou le ZF.
Le ZF remplace les _ par des /, Doctrine lui met en cache (via loadmodels) les chemins des fichiers. L'un ou l'autre pour moi, c'est pareil, ca prends qq mms pour trouvé le fichier demandé.

En conservative, Doctrine ne fait que mettre en cache les chemins, il n'inclus rien.

Faudrait vraiment détails tous les temps passé par ton application pour voir ou sa galerre

Profile ton application pour voir ou sa cloche

Dernière modification par nORKy (24-09-2009 12:18:33)

Delprog a écrit:

Salut,

Dans Zend_Db tout est lazy-loaded mais le chargement automatique des dépendances n'est pas géré (l'enregistrement non plus).
Le mapping n'est pas non plus disponible (bientôt vu les proposals).

Zend_Db_Table et Zend_Db_Table_Row assurent les fonctionnalités de base d'un ORM, à savoir manipuler les tables et les enregistrements des tables d'une base de données relationnelle comme s'il s'agissait d'une base de données orientée objet.

Pour Doctrine, dans mon plugin de resource

Code:

if (true === (bool)$this->_options['generate']) {       
            $genOptions = array(
                'baseClassPrefix' => $this->_options['options']['baseClassPrefix'],
                'classPrefix' => $this->_options['options']['classPrefix'],
                'classPrefixFiles' => (bool)$this->_options['options']['classPrefixFiles'],
                'baseClassesDirectory' => $this->_options['options']['baseClassesDirectory'],
                'generateTableClasses' => (bool)$this->_options['options']['generateTableClasses']
            );
            Doctrine::generateModelsFromYaml($this->_options['path']['schema'], $this->_options['path']['models'], $genOptions);
        }

Dans la conf

Code:

;====== Resource Doctrine
resources.doctrine.dsn = "mysql://user:password@localhost/schema"
resources.doctrine.generate = false
resources.doctrine.options.baseClassPrefix = Entity_
resources.doctrine.options.classPrefix = Model_
resources.doctrine.options.classPrefixFiles = false
resources.doctrine.options.baseClassesDirectory = Entity
resources.doctrine.options.generateTableClasses = true
resources.doctrine.path.schema = APPLICATION_PATH "/config/models.yml"
resources.doctrine.path.models = APPLICATION_PATH "/models"

Par contre attention, l'option "classPrefixFiles" ne sera dispo que dans la 1.2 qui est en Alpha. Il faut donc pour l'instant renommer les fichiers à la main (les noms des classes sont ok eux).
Perso j'utilise un logiciel pour ça, genre AntRenamer, c'est un peu lourd de se le palucher.

A+ benjamin.

J'ai repris la config de Benjamin cad que mes modeles sont générés dans /models et préfixés par Model_
et mes classes "Base" dans /models/Entity et préfixés par Model_Entity.

Dans mon bootstrap j'ai:

    public function _initDoctrine()
    {
    require_once 'Doctrine.php';   
    $doctrineConfig = $this->getOption('doctrine');
    //print_r($doctrineConfig);
    
    $loader = Zend_Loader_Autoloader::getInstance();
    $loader->pushAutoloader(array('Doctrine', 'autoload'),'Model_');

    $manager = Doctrine_Manager::getInstance();
    $manager->setAttribute(Doctrine::ATTR_AUTO_ACCESSOR_OVERRIDE, true);
    $manager->setAttribute(Doctrine::ATTR_AUTOLOAD_TABLE_CLASSES, true);
    $manager->setAttribute(
        Doctrine::ATTR_MODEL_LOADING,
        Doctrine::MODEL_LOADING_CONSERVATIVE
    );
echo time()."<br/>";
    // Add models and generated base classes to Doctrine autoloader
    Doctrine::loadModels($doctrineConfig['models_path']);
echo time()."<br/>";

    $manager->openConnection($doctrineConfig['connection_string']);     
    
    return $manager;
    }

Tout fonctionne parfaitement bien mais la commande
Doctrine::loadModels($doctrineConfig['models_path']);
met encore 4 secondes a s'exécuter (111 classes a charger).

Est ce que vous voyez quelque chose qui cloche dans cette fonction?

Delprog a écrit:

Le gros problème pour l'instant c'est l'option "classPrefixFiles" qui ne fonctionne pas encore et est prévu pour la version 1.2 (actuellement en Alpha). Du coup il faut renommer les fichiers après la génération.

A+ benjamin.

C'est pour ca que j'utilise loadModels. Comme on peut le voir plus, c'est très rapide chez moi, aucun pertes de performances. Mais dès que j'utiliserais la 1.2, je ne passerais plus par loadModels

Delprog a écrit:

Salut,

Non je n'ai pas implémenté de mapper. Simplement des DAO tout ce qu'il y a de plus basique.

Je me préparais justement à demander la différence entre dao et mapper, et j'ai trouvé ceci. Cool. Merci.

Dans ce cas, je me demande où se place Doctrine dans ton schémas:
Controller -> Service -> DAO -> Mapper -> Db à la place de Mapper?

Dernière modification par lesauf (02-10-2009 14:53:45)