Conversation
doc/article.md
Outdated
|
|
||
| J’aimerais vous présenter une autre alternative : | ||
|
|
||
| **Méconnu mais pourtant si pratique**, plein d’avantages, mais ayant certains prérequis, le mapping Doctrine avec PHP est un outil qui m’a personnellement beaucoup plu. C’est dans le cadre d’un projet **from scratch**, avec un découpage en oignon permettant une séparation claire des responsabilités en trois couches distinctes, que nous avons choisi d’utiliser le mapping Doctrine avec PHP. |
There was a problem hiding this comment.
| **Méconnu mais pourtant si pratique**, plein d’avantages, mais ayant certains prérequis, le mapping Doctrine avec PHP est un outil qui m’a personnellement beaucoup plu. C’est dans le cadre d’un projet **from scratch**, avec un découpage en oignon permettant une séparation claire des responsabilités en trois couches distinctes, que nous avons choisi d’utiliser le mapping Doctrine avec PHP. | |
| **Méconnu mais pourtant si pratique**, plein d’avantages, mais ayant certains prérequis, le mapping Doctrine avec PHP est une technique qui m’a personnellement beaucoup plu. C’est dans le cadre d’un projet **from scratch**, avec un découpage du code en oignon permettant une séparation claire des responsabilités en trois couches distinctes, que nous avons choisi d’utiliser le mapping Doctrine avec PHP. |
| public function __construct( | ||
| /** @ORM\Column(type="string", length=255) */ | ||
| private string $name | ||
| ){} |
There was a problem hiding this comment.
| public function __construct( | |
| /** @ORM\Column(type="string", length=255) */ | |
| private string $name | |
| ){} | |
| public function __construct( | |
| /** @ORM\Column(type="string", length=255) */ | |
| private string $name | |
| ){} |
| Même classe représentant notre modèle du domaine : | ||
| ```php | ||
| class User { | ||
| protected int $id; |
There was a problem hiding this comment.
| protected int $id; | |
| protected ?int $id; |
There was a problem hiding this comment.
j'ai rendu le retour de getId() non nullable plutôt.
doc/article.md
Outdated
| ## Inconvénients : | ||
|
|
||
| - La prise en main. | ||
| - Cela peut paraître verbeux à première vue. |
There was a problem hiding this comment.
à préciser car c'est aussi l'inconvénient de l'autre méthode
doc/article.md
Outdated
| - La prise en main. | ||
| - Cela peut paraître verbeux à première vue. | ||
|
|
||
| Comme vu sur les écrans, nous pouvons créer une entité qui étend notre modèle. Ensuite, **Doctrine** nous fournit tous les outils nécessaires pour créer notre mapping. Je conseille tout de même d’abstraire cette logique via des services personnalisé qui seront la seul partie du code a modifier en cas de changement d'ORM. Je vous invite à consulter la classe **ClassMetaData** de Doctrine et la classe **ClassMetaDataBuilder**. L’une permet de charger votre entité et l’autre de construire votre mapping. |
There was a problem hiding this comment.
| Comme vu sur les écrans, nous pouvons créer une entité qui étend notre modèle. Ensuite, **Doctrine** nous fournit tous les outils nécessaires pour créer notre mapping. Je conseille tout de même d’abstraire cette logique via des services personnalisé qui seront la seul partie du code a modifier en cas de changement d'ORM. Je vous invite à consulter la classe **ClassMetaData** de Doctrine et la classe **ClassMetaDataBuilder**. L’une permet de charger votre entité et l’autre de construire votre mapping. | |
| Comme vu sur les écrans, nous pouvons créer une entité qui étend notre modèle. Ensuite, **Doctrine** nous fournit tous les outils nécessaires pour créer notre mapping. Je conseille tout de même d’abstraire cette logique via des services personnalisés qui seront la seul partie du code à modifier en cas de changement d'ORM. Je vous invite à consulter la classe **ClassMetaData** de Doctrine et la classe **ClassMetaDataBuilder**. L’une permet de charger votre entité et l’autre de construire votre mapping. |
louislebrault
left a comment
There was a problem hiding this comment.
C'est simple et concis, c'est cool.
Je suis pas fan d'autant d'utilisation des pronoms possessifs (j'aimerais, je, nous, notre, etc...), je pense que le sujet pourrait etre amené de facon moins subjective, plus neutre.
doc/article.md
Outdated
|
|
||
| **Méconnu mais pourtant si pratique**, plein d’avantages, mais avec certains prérequis, le mapping Doctrine avec PHP est une technique qui m’a personnellement beaucoup plu. C’est dans le cadre d’un projet **from scratch**, avec un découpage du code en oignon permettant une séparation claire des responsabilités en trois couches distinctes, que nous avons choisi d’utiliser le mapping Doctrine avec PHP. | ||
|
|
||
| L’architecture choisie a pour but de séparer la partie métier pure des dépendances et interactions que peut avoir l’application. Ainsi, notre projet n’est pas fortement dépendant des modifications (non-maintenance ou suppression des librairies utilisées). |
There was a problem hiding this comment.
la vulgarisation est un peu maladroite et je pense que ça rend pas service au sujet principale de l'article que de tergiverser sur ce genre de considération complexe, le mapping des entités avec doctrine peut etre présenté comme une bonne pratique en dehors du contexte d'une archi hexagonale non ?
doc/article.md
Outdated
| - Sépare le modèle du domaine (classe **PHP** "pure") de son mapping dans l’infrastructure: Pas de dépendances dans notre logique métier. | ||
| - Cela permet une implémentation plus concise et logique. | ||
| - Nous évitons aussi la nécessité d’un troisième fichier de mapping, ce qui simplifie la structure du projet. | ||
| - **Testable !** |
doc/article.md
Outdated
|
|
||
| ## Inconvénients : | ||
|
|
||
| - La prise en main. |
There was a problem hiding this comment.
un peu flou pour moi ce qu'on entend par "prise en main"
doc/article.md
Outdated
| ## Inconvénients : | ||
|
|
||
| - La prise en main. | ||
| - Cela peut paraître complexe à première vue. |
There was a problem hiding this comment.
C'est très subjectif, on peut peut-etre plutot evoquer les criteres objectifs qui peuvent amener a considerer que l'approche est complexe.
doc/article.md
Outdated
| - La prise en main. | ||
| - Cela peut paraître complexe à première vue. | ||
|
|
||
| Comme vu sur les exemples, nous pouvons créer une entité qui étend notre modèle. Ensuite, **Doctrine** nous fournit tous les outils nécessaires pour créer notre mapping. Je vous invite à consulter la classe **ClassMetaData** de Doctrine et la classe **ClassMetaDataBuilder**. L’une permet de charger votre entité et l’autre de construire votre mapping. |
There was a problem hiding this comment.
ajouter des liens vers le repo de doctrine vers les classes concernées ?
doc/article.md
Outdated
| ->build(); | ||
| ``` | ||
|
|
||
| Je conseille tout de même d’abstraire cette logique via des services personnalisés qui seront la seule partie du code a modifier en cas de changement d'ORM. |
There was a problem hiding this comment.
Il vaudrait mieux en ce cas utilisé des exemples de cas qui ne sont pas déconseillés imho. Dans quel cas cette approche est-elle utile ?
doc/article.md
Outdated
|
|
||
| ## Conclusion | ||
|
|
||
| L’adoption de l’architecture hexagonale et du découpage en oignon, couplée à Doctrine, nous a permis d’organiser notre code de manière claire et évolutive. En séparant la logique métier des dépendances externes, nous gagnons en maintenabilité et en testabilité. De plus, le mapping PHP permet d’être couvert par des outils d'analyse statique comme **PHPStan**. |
There was a problem hiding this comment.
notion d'archi hexagonale hors sujet et dessert le propos imo
No description provided.