Cet article explique pourquoi Doctrine ORM sauvegarde les modifications des entités même sans appeler la méthode persist(). Le mécanisme clé est le "dirty checking" : Doctrine suit les entités gérées (chargées depuis la base de données), compare leurs valeurs actuelles avec une copie initiale, et génère des requêtes SQL uniquement pour les champs modifiés lors de l'appel à flush(). La méthode persist() n'est nécessaire que pour les nouvelles entités.
Tout est dans le titre
3 conférences résumées :
- L’aventure d’une requête HTTP — ou le chemin de la vie des devs -> il y a tant de concepts derrière que le conférencier insiste sur la modestie à avoir et sur le fait de se reposer sur ses coéquipiers
- Et si on repensait les ORMs ? -> présentation de l'ORM Format, un concurrent de Doctrine / Eloquent basé sur d'autres concepts (très bien fait pour le DDD)
- Webhooks at scale -> Le speaker présente le concept de Circuit Breaker
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
L'auteur donne son opinion sur l'intérêt ou non de découpler totalement les entités de l'ORM / Framework / ... Pour résumer, il faut que le modèle puisse être testé "en isolation" (sans base de données) mais y mettre des annotations (par exemple, Doctrine) n'est pas contre indiqué -> cela ne rend pas le modèle moins testable.
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre... mais les principes exposés ici s'appliquent à d'autres ORM comme Doctrine (a priori ?)
présentation de l'ORM Eloquent (utilisable avec le framework PHP Laravel)