Bonjour à tous. Je veux m'avouer devant vous et vous parler un peu de ce que je ressens quand je me développe sur Laravel. Non, n'y pense pas, j'adore ce framework et je suis incroyablement reconnaissant à l'équipe qui l'a créé et le soutient, ils font un travail extrêmement cool et, à mon avis, Laravel est la meilleure continuation de Symfony, non moins aimé de moi.
J'adore le code stupide. Bête en ce sens que même après 10 ans, si le client vous demande d'y apporter des modifications, vous pouvez le faire sans plonger dans la logique, même après avoir été après une fête d'entreprise vendredi, sans rien casser dans l'ancien code. Et stupide dans le sens où vous n'avez pas besoin de faire d'effort cognitif pour le comprendre. Mais il y a une solution architecturale dans Laravel Eloquent ORM qui me fait pleurer. Intéressant? Viens sous le chat.
Les gens intelligents ont tout inventé pour nous il y a longtemps: OOP, Design Patterns, SOLID, DDD et d'autres mots effrayants qui vous font tellement peur au début, puis les appliquent sur une intuition.
Ces j'aime Laravel et Symfony. Ils vous permettent d'écrire le code le plus stupide et sécurisé dès la sortie de la boîte. Oui Chacun a ses inconvénients ... Mais à Laravel, il y en a un qui me gêne le plus. Cela utilise Active Record Pattern (AR) pour travailler avec des modèles.
Pour commencer, un peu sur ce modèle. De quoi s'agit-il? Pour comprendre, vous devez vous adresser au parent de cet opus de conception d'application - le modèle de référentiel. Ce motif est une collection. Une collection d'entités (Entités) qui peuvent les récupérer, les modifier, les enregistrer, les supprimer, en général, les gérer dans un emplacement de stockage abstrait. Dans 90% des cas sur 100, cet emplacement de stockage est une variété de bases de données. Mais il peut y avoir un système de fichiers, une sorte de cache et même une API externe.
Cette approche est pleinement conforme au principe de la responsabilité partagée et à l'approche DDD. De plus, grâce à cette approche, une faible connectivité est mise en œuvre - nous ne nous soucions pas exactement de la façon dont l'application est stockée, nous travaillons avec Entity lorsque nous voulons travailler directement avec la représentation objet des données et travailler avec Repository lorsque nous devons interagir avec le référentiel.
Mais Laravel a décidé d'opter pour la RA, ce qui est indéniablement cool et incroyablement pratique lorsque vous devez créer un prototype rapide, mais cela devient un casse-tête incroyable lorsque vous devez interagir avec plusieurs sources de données et fonctionner avec elles dans le système.
AR est un modèle qui mappe l'entité et le référentiel en un seul modèle. C'est-à-dire qu'un objet devient une représentation d'un enregistrement particulier dans la base de données. Et ... quoi? À quoi cela mène-t-il et pourquoi est-ce si ennuyeux?
Premièrement, nous violons le même principe de responsabilité partagée - la logique de travailler avec le référentiel à un endroit et la logique de travailler avec une entité à un autre. Ceci est important, car dans le cadre de mon système, je ne souhaite pas transférer une ligne de la base de données dans la représentation d'objet via la chaîne d'appel. Je veux passer le modèle. Je ne devrais pas me soucier de la façon dont cela se passe, change et persiste. J'ai besoin de ces méthodes qui vous permettent d'interagir uniquement avec le modèle, et non avec les lignes de la base de données.
Deuxièmement, nous ne pouvons pas (en raison du fait que la couche persistante - la couche de stockage - est connectée à la couche d'entité), simplement changer l'emplacement de stockage du modèle. Oui, nous pouvons le faire dans la configuration, en le modifiant immédiatement pour tout le monde, dans les bases de données prises en charge. Ou modifiez uniquement pour un modèle spécifique (avec tout cela, nous ne supprimons aucune méthode de générateur de requête, car vous ne pouvez pas vous débarrasser des méthodes de classe de base) et rencontrez une tonne d'erreurs probables dans le code ou, Dieu nous en préserve, si quelqu'un d'autre soutiendra (et cela arrive tout le temps).
Troisièmement. Je veux tester mes entités. Je tiens à le damner pour être sûr que les changements que j'apporter ne briseront pas ma logique commerciale. Et, comme le montre la pratique, dans le cas de la RA, vous ne pouvez pas le faire, car le principe diabolique de la responsabilité unique a été violé! Bien qu'ici, je sois un peu hypocrite. Tester des modèles est possible, juste ... Un peu compliqué.
Néanmoins, il est impossible de ne pas parler des avantages de ce modèle. Bien que son plus, c'est qu'il est "rapide, simple, sans hésitation". En fusionnant deux modèles qui sont proches en logique de leurs actions et sont constamment utilisés ensemble, nous avons obtenu un outil pratique qui réduit légèrement la quantité de code (dans le sens de la complexité, nous souvenons-nous du "code stupide"?). Il vous permet également de vous débarrasser des problèmes inutiles au stade de la formation de MVP, ce qui est obligatoire (la pratique montre que cela se produit rarement, mais quand même), il est prévu de le réécrire. Cela vous permet de passer de la question «comment faisons-nous» à la question «que faisons-nous», c'est-à-dire de se débarrasser des questions inutiles sur les technologies et de passer à la logique métier.
À quelle conclusion suis-je parvenu au cours des années d'utilisation du Laravel Eloquent ORM? Active Record mal dans la chair? Non, c'est l'outil le plus cool pour certaines situations, en particulier pour l'étape où vous écrivez une application simple ou un prototype d'une telle application. Mais c'est une chose impossible à travailler lorsque votre application grandit et que vous devez travailler avec un grand nombre de sources de données, écrire du code avec une couverture de test à 100% et de gros problèmes commencent.
Oui, de nouvelles puces sont en train d'être inventées ( Trucker ?), Mais allons-y pour des trucs. Mais je veux quand même un peu plus de liberté par rapport au cadre, d'autant plus qu'il est si bon pour tant de gens!