Zend FR

Salut,

Peux-tu présenter en quelques mots les avantages de Doctrine par rapport à Zend_Db.
J'ai cru comprendre que tu disais qu'il générait le mapping automatiquement ?
Et sinon, pourquoi est-il mieux ?

Merci

Je commence tout juste à découvrir Zend_Db, c'est le premier ORM que j'utilise.
Il est vrai qu'il manque un outil type Zend_Tool pour générer ses mappings.
Il existe bien un Zend_Generator qui le fait mais ca reste très "bricole".

En fait, je ne connais pas du tout Doctrine et Propel et justement connaitre cette différence, savoir ce qu'ils peuvent apporter de plus (à part la génération automatique).

Merci

The Doctrine ORM is mainly built around the Active Record, Data Mapper and Meta Data
Mapping patterns.
Through extending a specific base class named Doctrine_Record, all the child classes get
the typical ActiveRecord interface (save/delete/etc.) and it allows Doctrine to easily
participate in and monitor the lifecycles of your records. The real work, however, is mostly
forwarded to other components, like the Doctrine_Table class. This class has the typical
Data Mapper interface, createQuery(), find(id), findAll(), findBy*(),
findOneBy*() etc. So the ActiveRecord base class enables Doctrine to manage your records
and provides them with the typical ActiveRecord interface whilst the mapping footwork is
done elsewhere.
The ActiveRecord approach comes with its typical limitations. The most obvious is the
enforcement for a class to extend a specific base class in order to be persistent (a
Doctrine_Record). In general, the design of your domain model is pretty much restricted
by the design of your relational model. There is an exception though. When dealing with
inheritance structures, Doctrine provides some sophisticated mapping strategies which allow
your domain model to diverge a bit from the relational model and therefore give you a bit
more freedom.
Doctrine is in a continuous development process and we always try to add new features that
provide more freedom in the modeling of the domain. However, as long as Doctrine remains
mainly an ActiveRecord approach, there will always be a pretty large, (forced) similarity of
these two models.
After mentioning these drawbacks, it's time to mention some advantages of the ActiveRecord
approach. Apart from the (arguably slightly) simpler programming model, it turns out that the
strong similarity of the relational model and the Object Oriented (OO) domain model also has
an advantage: It makes it relatively easy to provide powerful generation tools, that can create
a basic domain model out of an existing relational schema. Further, as the domain model
can't drift far from the relational model due to the reasons above, such generation and
synchronization tools can easily be used throughout the development process. Such tools are
one of Doctrine's strengths.
We think that these limitations of the ActiveRecord approach are not that much of a problem
for the majority of web applications because the complexity of the business domains is often
moderate, but we also admit that the ActiveRecord approach is certainly not suited for
complex business logic (which is often approached using Domain-Driven Design) as it simply
puts too many restrictions and has too much influence on your domain model.
Doctrine is a great tool to drive the persistence of simple or moderately complex domain
models(1) and you may even find that it's a good choice for complex domain models if you
consider the trade-off between making your domain model more database-centric and
implementing all the mapping on your own (because at the time of this writing we are not
aware of any powerful ORM tools for PHP that are not based on an ActiveRecord approach).

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

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

;====== 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.

Maintenant que je suis lancé sur Doctrine, je risque d'avoir des questions à ce sujet.
J'vais continuer sur ce topic, ceux qui l'utilise seront p'tête me répondre.

Voici quelque chose que je ne comprends pas.

$oPDO   = new PDO('mysql:host=' . Conf_Bdd::HOST . ';dbname=' . Conf_Bdd::DB, Conf_Bdd::USER, Conf_Bdd::PASS);
$oDMan = Doctrine_Manager::getInstance();
$oDMan->setCharset(Conf_Bdd::CHARSET);
$oDCon = Doctrine_Manager::connection($oPDO);
echo $oDCon->getCharset();

Si je définis le charset via le Doctrine_Manager je ne récupère pas les données de la base avec le bon encodage.
Je suis obligé de faire un $oDCon->setCharset(Conf_Bdd::CHARSET); pour que cela soit pris en compte.
Pourquoi ? Pourtant lorsque je fais un $oDCon->getCharset(); je vois bien utf8.

Merci

Non puisque ça fonctionne lorsque je précise utf8 à l'objet Doctrine_Connection.

Mais pas à Doctrine_Manager.
Or mon Doctrine_Connection devrait hériter des propriétés des Doctrine_Manager, et c'est le cas puisque $oDCon->getCharset(); me retourne bien utf8. Sauf que ça ne fonctionne pas.

Attention dans le DQL ce n'est pas la table que tu utilises dans les clauses mais l'entité.

Si j'ai un objet métier Model_User, Doctrine va aussi me créer une table Model_UserTable, mais dans mes requêtes en DQL je vais avoir:

$q = Doctrine_Query::create();
$q->from('Model_User u')
  ->leftJoin('u.profil p')    // profil = nom de la propriété dans la relation (pas de la table)
  ->where('u.id = ?', 1);  // id = nom de la propriété, pas du champ dans la table

Ce qui correspond au Yaml suivant:

---
User:
  tableName: user
  columns:
    login: string
    password: string
  actAs:
    Timestampable:
      created:
        name: created  
        type: timestamp
        format: Y-m-d H
      updated:
        name: updated
        type: timestamp
        format: Y-m-d H
  relations:
    profil:
      class: Profil
      local: id
      foreign: user_id

Profil:
  tableName: profil
  columns:
    user_id:
      name: user_id as userId
      type: integer
    name: string
    email: string
    birthDay: date
    gender: string
  relations:
    user:
      class: User
      local: user_id
      foreign: id

Dans les requêtes DQL on ne manipule que des entités, même les join se font avec le nom de la propriété qui contient les dépendances dans les entités. C'est pour ça qu'on ne précise d'ailleurs jamais la jointure avec une table de relations pour du many-to-many, c'est automatique.

Pour créer un objet (je fais pas le save dans le controlleur, mais dans l'idée c'est ça)

$user = new Model_User();
$user->login = 'login';
$user->password = md5('password');
$user->profil->name = 'Dorian';
$user->save();

$user = $this->_userService->getUserById(1);
echo $user->profil->name;

Je n'ai aucun problème avec tout ça.

Je t'invite à faire des recherches sur google pour bien intégrer et initialiser Doctrine avec ZF, notamment le blog de Matthew (http://weierophinney.net/matthew/archiv … ework.html), à bien lire la doc de Doctrine, pas en travers, comme elle n'est pas très bien faite, il faut tout lire pour trouver les infos et de poser tes questions sur le googlegroup de doctrine qui est assez réactif. Ici c'est pour ZF


A+ benjamin.

Dernière modification par Delprog (22-09-2009 16:41:48)

dorian53 a écrit:

Delprog a écrit:

$user = new Model_User();
$user->login = 'login';
$user->password = md5('password');
$user->profil->name = 'Dorian';
$user->save();

Ici par exemple je ne suis pas d'accord, logiquement tu fois faire un $user->Model_Profil->name = 'Dorian';
Et ca fait parti des points qui me chagrine, niveau code c'est moins fun.
Je me trompe ?

Qu'est ce qui te choque ?? Profil est un objet "de la table". Dans Doctrine, il n'y pas de prefix 'Model', et perso, j'en vois pas l'interet.
A mon avis, Delprog à "buggué" en écrivant Model_User. Soit tu préfix tous, soit tu ne le fais pas.


Autre astuce pour ne pas avoir à faire '->from('xxx')' (car j'ai vu que ca ne te plaisais pas )

class UserTable extends Doctrine_Table {
  public function findSpecial($id)
  {
    return 
     $this->createQuery('u')
     ->lefJoin('u.profile')
     ->leftJoin('u.Adresse a')
     ->leftJoin('a.Phonenumbers p')
     ->where('id = ?', array($id))
     ->fetchOne();      
  }
}

PS : j'utilise doctrine depuis ses premières versions

Delprog a écrit:

Si tu regardes bien mon yaml, j'ai forcé le nom des propriétés et défini explicitement le nom de la classe correspondante

Voila la phrase qui répond à toute cette mésentente.
Oké, merci.

Mon outils de génération Yaml ne génère pas de tableName pour les tables simples voilà pourquoi j'ai dit ça plutôt.

dorian53 a écrit:

Parce qu'il n'y a aucun alias de généré automatiquement dans les "hasOne".

Et ça répond maintenant à l'interrogation sur le préfixe, moi j'étais obligé d'appeler le modèle pour utiliser la propriété (issu du modèle).

Au final nous sommes tous d'accord.

Je suis ravi d'avoir découvert cette librairie.

Bonne journée à vous.

Ce n'est pas comme ça qu'il faut définir une relation.

Ce code:

profil:
   tableName: profil
....

User:
   relations:
      class: profil
...

devrait être:

profil:
   tableName: profil
....

User:
  relations:
      profil:
        class: Profil
        local: id
        foreign: user_id
...

Où "profil" sera le nom de la propriété dans User et "Profil" sera la classe de référence.

Je génère le yaml depuis la base au tout départ et ensuite je maintiens à la mano parce que je redéfinis pas mal d'alias pour conserver des objets métiers détachés de la BDD (on sait jamais, si je me défais de Doctrine).

Perso, je déteste le Yaml et préfère largement le XML, plus lisible et tu peux mettre plusieurs propriétés sur une même ligne. Mais c'est comme ça, c'est le choix de Doctrine.
Sauf si Zend sort un Zend_Config_Yaml et qu'on peut passer d'un XML à un Yaml grâce à ça un jour :p


A+ benjamin.

Par contre j'vois pas du tout comment se défaire facilement de Doctrine.

Arrête ne me lance pas sur ce sujet

En bref, Doctrine génère des entités qui pour lui correspondent à des tables. Je fais en sorte, grâce aux alias de lui faire construire les objets comme j'aurais construit les objets métiers sans lui (sans tenir compte de la persistance).

Ensuite dans les controlleurs je n'utilise jamais rien d'autre que ce que j'utiliserais avec des objets métiers, en gros :

$user->login;
$user->login = 'login';
$user->profil->name;
$user->profil->name = 'name';
$user->toArray();
$user->fromArray($array);

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 biensûr


A+ benjamin.

Dernière modification par Delprog (23-09-2009 11:54:21)

Voici un exemple tout simple que j'ai essayé de mettre en place.
Suis-je dans l'esprit ?

class DAO_Table {

    protected $_oMetier;

    public function __construct($poMetier) {
          $this->_oMetier = Doctrine::getTable(poMetier);
    }

    public function find($pId) {
        return $this->_oMetier->find($pId);
    }

}

Le soucis c'est qu'il faut également abstraire le return du find() ?
Faire un DAO qui a l'objet Doctrine_Record en attribut ?

C'est vrai que c'est lourd comme tout DAO mais très sage.

Mais si on pousse un peu plus loin...
J'image que chaque Doctrine_Query est utilisée dans une méthode du DAO_Table ?
Que tu fais abstraction de la valeur retour du Doctrine_Query, tu as un DAO Doctrine_Collection ?

S'il faut faire comme ça, là ca devient super long.

À coté de la plaque ou en gros c'est ça ?