Avantages du modèle de référentiel : pourquoi devrions-nous l’envisager ?
Hier, j’ai donné une amorce sur le modèle de référentiel. En bref, c’est l’un de ces modèles que je pense que toute personne travaillant sur un middleware construit sur WordPress devrait comprendre.
Lorsque vous donnez une introduction à un motif comme celui-ci, il peut être difficile de rendre justice au motif lorsque vous devez :
- le présenter,
- expliquer comment ça marche,
- couvrir les prestations,
- et faire une petite démo.
Mais le véritable avantage du référentiel réside non seulement dans l’abstraction de la couche de données du reste de l’application, mais aussi dans le fait qu’elle peut (ou devrait) pouvoir être facilement échangée avec divers magasins de données sans changer l’API.
Par exemple, dans un cas, vous devrez peut-être récupérer des données de la base de données WordPress, dans d’autres cas, vous devrez peut-être récupérer quelque chose à partir d’une API tierce, ou peut-être qu’il y a un autre endroit à partir duquel vous devez récupérer des données.
Quoi qu’il en soit, l’idée derrière le modèle de référentiel est que tout ce qui se trouve derrière n’a pas d’importance tant que l’API qu’il fournit fonctionne pour la couche de l’application qui l’appelle.
Et puisque nous avons couvert une introduction au modèle de référentiel, examinons certains des avantages du modèle de référentiel et comment nous pouvons l’implémenter dans le contexte de projets WordPress.
Avantages du modèle de référentiel
Il existe plusieurs façons de commencer à expliquer le modèle, je vais donc commencer par un schéma simple :
Les avantages du modèle de référentiel incluent l’abstraction du magasin de données
Remarquez dans l’image ci-dessus, il y a trois composants principaux :
- la logique de domaine (ou la logique métier) que j’ai étiquetée "App",
- le référentiel,
- le magasin de données,
Concernant l’application, les règles métier resteront toujours relativement cohérentes. Au moins, ils devraient, non?
Le référentiel est ce qui agit comme un moyen de communication entre la logique métier et le magasin de données.
Désormais, le magasin de données peut être une base de données, peut-être un ensemble de fichiers (ce que je ne recommanderais pas), une API destinée à un tiers, une liste d’informations extraites d’une autre application, etc.
Le fait est que le référentiel fournira une API propre dans laquelle la logique métier peut écrire et lire (et plus à ce sujet dans un instant) sans se soucier des détails sur l’endroit où les données vont ou comment elles reviennent.
C’est le travail du référentiel. Et c’est ce qui rend important d’avoir une API cohérente et c’est ce qui est important pour s’assurer qu’elle dispose des détails d’implémentation du magasin de données avec lequel elle interagit.
Sur couplage
En plus d’avoir votre application correctement segmentée, le modèle de référentiel profite à l’architecture en ce sens qu’il aide à découpler les parties de votre application.
C’est-à-dire que la logique métier ne sait rien de comment ni où les données sont stockées. Il sait juste qu’il peut l’écrire et le récupérer et il peut le faire en utilisant une API propre.
Le référentiel est responsable de la communication dudit magasin de données pour orchestrer la sérialisation et la récupération, mais doit fournir une API cohérente, de sorte que la couche de données n’a pas à faire de gymnastique syntaxique pour lire et écrire ses informations.
Détails d’implémentation
Jusqu’à présent, j’ai représenté le référentiel comme une classe concrète.
Le fait est qu’une application aura probablement plusieurs référentiels. Et à cause de cela, c’est une bonne idée d’avoir des interfaces que chaque référentiel peut implémenter.
C’est ainsi que vous définissez le contrat de méthodes que le référentiel fournira. Et c’est ainsi que vous pouvez vous assurer que chaque référentiel est connecté au magasin de données approprié.
Une implémentation d’interface pour plusieurs référentiels.
Supposons donc que votre application doive communiquer avec la base de données WordPress ainsi qu’avec une API tierce.
Idéalement, l’interface fournirait un ensemble commun de méthodes, mais les détails de mise en œuvre varieraient en fonction du référentiel, car chaque référentiel disposera des informations d’identification nécessaires et de la capacité de communiquer avec le magasin de données.
L’avancée vers l’interface est cependant ce qui donne au motif sa puissance. La logique du domaine n’a pas à se soucier de la manière dont les informations sont enregistrées ou récupérées. Il appelle simplement les méthodes telles que définies dans l’interface et l’objet nécessaire s’en charge.
Il appelle simplement les méthodes telles que définies dans l’interface et l’objet nécessaire s’en charge.
À quoi cela ressemblerait-il dans WordPress ?
C’est une bonne question (et non je ne l’ai pas inventée juste pour y répondre par moi-même 🙂), et il peut être difficile de donner un bon exemple car une grande partie de ce que nous faisons interagit directement avec la base de données WordPress.
Cela ne signifie pas qu’il n’y a pas d’abstractions que nous pouvons utiliser telles que les publications, les pages, les utilisateurs ou tout autre type de publication personnalisé que nous choisissons de créer.
Mais WordPress fournit une API pour une grande partie de cela. Je peux voir un cas dans lequel, par exemple, un utilisateur avec des champs supplémentaires qui ont été ajoutés pourrait bénéficier d’un référentiel d’utilisateurs.
Ou un type de publication personnalisé avec beaucoup de métadonnées pourrait également bénéficier d’un référentiel en ayant les détails encapsulés dans le référentiel.
Un exemple de haut niveau
Supposons, par exemple, que vous ayez un type de publication personnalisé pour un événement, et que l’événement ait un titre et une description qui s’intégreraient naturellement dans le titre et le contenu de la publication.
Mais ensuite, il a des métadonnées sur son emplacement, son heure de début, son heure de fin, etc. Cela pourrait également être encapsulé par le référentiel afin que vous puissiez avoir un objet Event, le transmettre au référentiel, puis laisser le référentiel envoyer les informations au bon endroit dans la base de données.
Et il en va de même pour la récupération des informations: il sait où les obtenir, comment remplir un objet Event, puis les restitue à l’appelant.
Retour sur la bonne voie
Mais toutes ces discussions sur un événement deviennent un peu hors sujet, alors je vais peut-être continuer à en parler et comment cela s’intègre au référentiel dans un post de suivi. De toute évidence, quand on parle de cela, il y a beaucoup à couvrir.
Je préfère le faire par petites étapes
En bref, si vous avez un référentiel d’événements, vous avez probablement un objet Event ou une entité Event. Et la façon dont cela s’intègre dans WordPress, les types de publication personnalisés, les métadonnées, etc. introduit un niveau de complexité qui peut sembler intimidant au début, mais qui finit par payer lorsque vous travaillez avec une application Web plus grande.