Quelles différences il y a entre Eloquent et Doctrine2 ?

En fait, chacun utilise un pattern différent. Eloquent implémente Active Record, qui est généralement plus facilement utilisable. Doctrine2 quant à lui, implémente le pattern Data Mapper. Je vous renvoie aux fiches Wikipédia [1][2] pour en savoir plus si ces 2 termes sont abstraits pour vous, ici on va se concentrer sur Eloquent et Doctrine2.

Eloquent

Quand vous prenez un modèle Laravel, une fois instancié, vous pouvez directement appeler la méthode save() dessus. Etant donné que ce modèle étend Eloquent, c’est Eloquent qui va directement s’occuper de la sauvegarde et de la restauration des données : La persistance.

Doctrine2

Même si ça se passe autrement pour Doctrine, en regardant un modèle, on s’aperçoit qu’il n’étend aucune classe. Donc il ne traitera pas directement avec la base de données, et vous devez donc définir toutes les propriétés du modèle puisqu’il n’est pas directement connecté à la base.
Ce qui rend potentiellement Doctrine plus léger (en mémoire) à l’usage.

Migrations VS Annotations

Là où Laravel va gérer la structure de la base de données, via des fichiers de migration qui sont executé manuellement, Doctrine2 va utiliser un système d’annotation pour que l’Entity Manager puisse structurer la base en fonction de ce qui a été décrit.

Voici l’exemple d’annotation pour Doctrine, directement extrait de la documentation :

<?php
/**
 * @Column(type="string", length=32, unique=true, nullable=false)
 */
protected $username;

/**
 * @Column(type="string", columnDefinition="CHAR(2) NOT NULL")
 */
protected $country;

/**
 * @Column(type="decimal", precision=2, scale=1)
 */
protected $height;

/**
 * @Column(type="string", length=2, options={"fixed":true, "comment":"Initial letters of first and last name"})
 */
protected $initials;

/**
 * @Column(type="integer", name="login_count" nullable=false, options={"unsigned":true, "default":0})
 */
protected $loginCount;

Ca a l’avantage de déresponsabiliser le développeur sur la gestion de la base. Avec Eloquent, et plus particulièrement avec Laravel, si tu ne mets pas les bonnes infos dans la méthode down(), tu peux simplement tout casser.

L’Entity Manager

Vu que votre modèle ne s’occupe pas de la persistance, c’est l’entity manager qui s’en charge. Le résultat c’est qu’il faut écrire beaucoup plus de choses pour le même résultat, mais l’avantage c’est la légèreté.

Voici comment on va créer, et sauvegarder une propriété avec Eloquent :

<?php
$user = new User;
$user->email('foo@bar.com');
$user->save();


EntityManager::persist($user);
EntityManager::flush();

Et voici comment ça se passe pour Doctrine2 :


<?php
$user = new User;
$user->setEmail('foo@bar.com');

EntityManager::persist($user);
EntityManager::flush();

En gros, la différence vient du fait que persist() est utilisé pour générer la transaction vers la base de donnée. Flush() est appelé pour valider la transaction et faire la modification dans la base de données.

Setters && Getters

Là aussi une différence fondamentale, toujours liée au fait que le modèle n’a aucun lien avec la base de données :
Là où Eloquent va aller chercher les propriétés demandées dans la base de données (si le champ existe), Doctrine2 a besoin d’avoir tous les getters et tous les setters pour accéder à un champ.

Donc là aussi, Doctrine2 va être plus verbeux, mais ça a l’avantage d’en savoir tout de suite plus sur son modèle aussi. Et n’oublions pas encore, la légèreté.

Les requêtes

Bel avantage pour Eloquent sur ce point selon moi. La grande majorité des requètes avec Eloquent peut se faire avec une véritable syntaxe PHP. C’est à dire que tu n’écris presque plus de SQL.
Forcément, écrire peu de requète SQL a ses avantages, et ses inconvénients, mais ce n’est pas le sujet ici. Au quotidien, je trouve ça pratique quand même.

Requêtes Eloquent

<?php

$users = User::where('email', strtolower($user->email))->whereNotNull('deleted_at')->get();

Requêtes Doctrine2

<?php

$query = EntityManager::createQuery("select u from User u where u.email = LOWER({$email}) and u.deteled_at IS NOT NULL");

$users = $query->getResult();

Lequel choisir

Il n’y a pas de meilleur choix, les 2 ont leurs avantages – oui, et leurs inconvénients aussi. Au début on peut être plus facilement accroché par Eloquent, et Active Record donc. Plus simple, moins verbeux etc. Ca passe pour toutes les applications CRUD, et c’est très bien.

Vu que je préfère éviter les débats Vim/Emacs, Chocolatine/Pain au chocolat, je vous recommande la lecture de ce billet (en) qui vous donnera des pistes pour choisir lequel correspond le mieux à votre application.

Recherches utilisées pour trouver cet article :doctrine vs eloquent, eloquent vs docteine
metrogeek

Laisser un commentaire