Custom types embeddables

index.md

@@ -30,6 +30,11 @@ Maxime Veber
     └── Twig
 </pre>
 
+Notes:
+- Aucune idée de ce que fait l'application
+- Tout ce qu'on reconnait, c'est des répertoires qui sont présents sur d'autres
+  applications.
+
 ---
 ### Vous avez dit entité ?
 
@@ -53,6 +58,7 @@ Notes:
 - Pas de validation
 - Pas de règles métier
 - Aucune logique (pas de tests nécessaires)
+- Pas de setter pour id, il est setté par Doctrine après la persistence
 
 ---
 ### Nous aimons le DDD
@@ -61,6 +67,9 @@ Notes:
 - Représenter les **règles métier** dans les entités
 - Avoir une API expressive
 
+Notes:
+- Il existe d'autres architectures, cf le talk sur le clean code de Romain Kuzniak
+
 ---
 ### Doctrine n'a pas besoin de setters
 
@@ -183,7 +192,11 @@ Note:
 - La méthode `getName()` fait doublon avec le nom utilisé lors de
   l'enregistrement du type dans le registre de type, et disparaître dès Doctrine 3
 - `ArticleId` devrait être une clé naturelle ou un UUID, le principal c'est de
-  pas avoir besoin de demander à la DB de le calculer
+  pas avoir besoin de demander à la DB de le calculer, ça évite des attaques
+pour cause d'ID devinables, et ça évite d'exposer le nombre d'entités présentes
+dans une table. Ça évite aussi des collisions lorsque vous migrez des données
+d'une base vers une autre, et que la nouvelle base peut elle aussi être
+alimentée directement.
 
 ---
 ### Les constructeurs nommés
@@ -202,6 +215,7 @@ Note:
 - On peut faire plusieurs constructeurs nommés
 - On peut passer le constructeur en privé pour encourager l'utilisation des
   constructeurs nommés.
+
 ---
 ### Les repositories
 
@@ -227,8 +241,13 @@ final class DoctrineArticleRepository implements ArticleRepository
 ```
 
 Note:
-- `Repository`, c'est un pattern, et il vaut mieux définir les vôtres sous
-  forme d'interface.
+- `Repository`, c'est un pattern, et c'est vous qui devriez en définir
+  l'interface.
+- `EntityRepository` et ses méthodes magiques à éviter si vous voulez des type
+  hints de retour et donc de l'autocompletion. Il est maintenant possible d'en
+faire des services: https://github.com/doctrine/DoctrineBundle/pull/727, mais
+ça ne résout pas le problème. Si vous tenez à les utiliser, injectez les dans
+vos repositories plutôt que de les étendre.
 - Plus l'interface est grosse, plus elle devient difficile à implémenter, et le
   code qui consomme l'API a rarement besoin de faire beaucoup d'appels, du
 coup… slide suivant
@@ -260,6 +279,35 @@ final class DoctrineGetLatestArticles implements GetLatestArticles
 Note:
 - Tout de suite beaucoup plus simple à réimplémenter en elasticsearch
 
+---
+# Les collections
+
+- elles permettent à Doctrine de repérer les changements
+- elles permettent à Doctrine de faire du lazy-loading
+- vous pouvez les éviter en type hintant `iterable` et en utilisant un tableau
+  pour les initialiser.
+- si une collection comporte énormément d'éléments, c'est probablement une
+  relation à faire sauter
+
+---
+# Faire une jointure avec une relation uni-directionnelle
+
+```php
+$queryBuilder
+  ->select('a.*')
+  ->from(Article::class)
+  ->innerJoin(Comment::class, 'c', Expr\Join::WITH, 'c.article_id = a.id')
+  ->where("c.content LIKE '%Doctrine%'")
+  ->getQuery()
+  ->getResults();
+```
+
+Note:
+- utile si on a besoin de rajouter des conditions sans nécessiter d'hydrater
+  des objets de la classe jointe.
+
+
+
 ---
 # Emoji test