L’amorce du modèle de référentiel

Chaque fois que vous travaillez sur un projet plus important basé sur WordPress, les chances que vous travailliez avec plus d’une source de données, c’est-à-dire la base de données WordPress, sont plus élevées que la normale. Par exemple, vous travaillez peut-être sur un projet qui doit coordonner des informations provenant de :

• la base de données WordPress,
• un système de ticket d’assistance,
• un système d’importation de contenu,
• une autre API tierce,
• et éventuellement plus.

Et lorsque cela se produit, il peut devenir un peu fastidieux d’écrire du code qui facilite la récupération d’informations à partir de ces différents endroits. C’est ce dont les développeurs parlent généralement lorsqu’ils se réfèrent à la gestion des "couches" dans leur application.

• il y a des couches pour présenter des informations à l’utilisateur, des
  couches pour gérer la logique métier (ou logique de domaine),
• des couches pour communiquer avec les API,
• et des couches pour stocker des données.

Honnêtement, vous n’avez pas besoin d’avoir une variété de magasins de données à surveiller pour créer une couche qui facilite l’envoi et la récupération des données de la base de données, c’est juste quand c’est plus courant. Vous pouvez tout aussi efficacement travailler avec un seul magasin de données, comme la base de données WordPress, lors de la mise en œuvre du modèle de référentiel.

Quoi qu’il en soit, si vous créez un site Web, une application Web ou un plug-in de plus grande taille, la mise en œuvre du modèle de référentiel peut s’avérer payante en termes de maintenance, de clarté du code et de séparation des préoccupations.

Mais comment cela pourrait-il être implémenté dans WordPress? Ce n’est pas très difficile, mais d’abord, cela vaut la peine de revoir une introduction au référentiel avant de sauter dans n’importe quel code.

Une introduction au modèle de référentiel

Avant d’examiner une implémentation réelle dans WordPress, il est important de comprendre ce qu’est le référentiel, comment il est défini, ce qu’il propose et une implémentation générique de celui-ci. Je partagerai quelques lectures supplémentaires à la fin de l’article, mais jusque-là, je couvrirai ici mon point de vue général sur le modèle.

Tout d’abord, une mise en œuvre de ce modèle peut devenir plus compliquée que nécessaire pour les débutants. Cela ne veut pas dire que le modèle réel ne vaut pas la peine d’être compris, mais si vous cherchez simplement à vous mouiller avec cela, je ne suis pas fan de jeter les lecteurs dans les profondeurs. Je ne pense pas que ce soit la meilleure façon d’apprendre.

Au lieu de cela, cela vaut la peine de décomposer le problème puis de le reconstruire en quelque chose d’un peu plus élégant. C’est donc ce que je vais essayer de faire.

Un mot sur le découplage

Quand on parle de programmation orientée objet, on parle souvent de l’idée de "découpler" des parties du système. Si vous êtes familier avec le couplage et la cohésion, alors vous savez pourquoi.

Mais si ce n’est pas le cas, il suffit de dire que plus les composants de votre système sont couplés, plus ils sont difficiles à modifier. Ils en savent trop l’un sur l’autre. C’est-à-dire que si vous changez l’un des aspects du système, cela va probablement se répercuter en cascade ou avoir un impact sur une autre partie du système que vous n’auriez jamais voulu voir se produire. Ensuite, vous devez passer beaucoup plus de temps à réparer tous ces autres "points de contact" dans le système qui ne devraient pas être nécessaires.

La mise en œuvre de diverses stratégies, comme le modèle de référentiel, peut aider à découpler des parties du système. Exemple concret : la couche de présentation ne sait pas comment le magasin de données sous-jacent est organisé. Il n’a pas besoin de connaître SQL. Il n’a pas besoin de savoir qu’il s’agit d’une base de données. Au lieu de cela, il a juste besoin de savoir comment parler au référentiel.

Bonne droite?

Cela signifie que vous pouvez échanger le magasin de données principal et, en supposant que votre API est solide ; votre application continuera à fonctionner avec peu ou pas de changement. Et c’est ce que cela signifie d’être vraiment découplé.

Une implémentation du modèle de référentiel

Alors, à quoi ressemble le modèle de référentiel ? Comme pour la plupart des modèles de conception, il existe une forme générique du modèle, et c’est toujours utile, mais je pense que cela aide également ceux d’entre nous qui travaillent dans WordPress à voir comment cela pourrait fonctionner dans le contexte de, vous savez, WordPress. 

Donc, d’abord, je veux décomposer le modèle lui-même, puis donner un exemple de ce à quoi il pourrait ressembler lorsque vous travaillez avec WordPress.

Une implémentation générique du modèle de référentiel

L’implémentation réelle du modèle de référentiel est assez simple. En fait, je ne suis jamais sûr que ce soit si utile, car cela montre simplement comment les magasins de données, le référentiel et le reste de l’application interagissent les uns avec les autres.

Ne vous méprenez pas: je suis pour les modèles conceptuels de la façon dont les choses sont organisées. Personnellement, cela m’aide à réfléchir à la structure d’une application lors de sa construction, mais si c’est trop général, ce n’est pas d’une grande aide.

Mais pour arriver à un outil concret, il faut bien commencer quelque part, n’est-ce pas? Donc, je vais commencer au plus haut niveau possible et travailler vers le bas.

Comme vous pouvez le voir dans l’image ci-dessus, vous avez quelques magasins de données qui sont tous lus via le référentiel, puis l’application interroge le référentiel qui, à son tour, récupère les informations du magasin de données.

Oui, il existe des options pour mettre en cache les informations, invalider le cache et toutes ces choses amusantes. Mais cela sort du cadre d’un primaire du référentiel. Je ne vais donc pas m’engager dans cette voie particulière pour l’instant. Peut-être dans un prochain post (si celui-ci s’avère utile pour vous).

Le modèle de référentiel dans WordPress

Cela dit, examinons une implémentation de base de ce à quoi cela pourrait ressembler dans une installation WordPress standard. Autrement dit, tout ce que nous avons est le magasin de données. Nous ne communiquons avec rien d’autre, mais nous voulons nous assurer que tout ce qui s’interface avec la base de données ou l’API est géré par le référentiel

Cela ressemblerait à ceci :

À quoi cela pourrait ressembler avec WordPress

Et cela peut être encore plus abstrait. Peut-être y a-t-il un dépôt de publication ou un dépôt d’utilisateurs. Personnellement, je suis fan d’avoir un référentiel pour chaque type d’entité car cela aide à contenir la logique métier associée sans créer ces grandes classes qui savent tout (et inutilement).

Cela pourrait donc ressembler à ceci :

Un ensemble de référentiels

Prenons ensuite un niveau supplémentaire et disons que vous travaillez avec l’API Twitter, l’API ZenDesk, l’API utilisateur WordPress et l’API WordPress Post. Alors quoi? Il y a plus de dépôts.

Peut-être qu’ils sont contenus dans leur espace de noms (ce qu’ils devraient être), peut-être qu’ils implémentent une interface commune (pour laquelle il y a un cas pour cela), mais pendant le temps de développement, je pense qu’il est important d’indiquer explicitement quel référentiel vous utilisez donc pour être le plus clair possible.

Autrement dit, n’utilisez pas de générique et laissez le runtime le comprendre :

$support_repository = new Support_Repository();
$support_repository->get_tickets_for( 'tommcfarlin' );

Soyez plutôt explicite :

$zendesk_repository = new ZenDesk_Repository();
$zendesk_repository->get_tickets_from( 'yesterday' );

Cela peut sembler beaucoup. Je ne sais pas si vous rencontrez cela, mais il y a un sentiment étrange dans la programmation orientée objet où nous voulons créer les petites classes ciblées mais cela crée beaucoup de fichiers.

Vous avez donc ces fichiers soigneusement configurés, chacun faisant quelque chose de petit et de utile. Ne laissez pas le nombre de fichiers qui composent un projet donner l’impression que vous avez une mauvaise architecture.

Conclusion

Ceci est l’amorce du modèle de référentiel. Naturellement, il y a du code qui va avec, mais avant de plonger dans cette partie – parce que le code est l’endroit où les choses se perdent facilement dans la traduction – je voulais m’assurer d’avoir aidé à fournir une illustration pour développer un modèle conceptuel du fonctionnement du modèle.

À partir de là, nous pouvons commencer à parler d’une implémentation du modèle. Donc, au cours du prochain article ou des deux prochains articles, je vais faire exactement cela.

En attendant, n’hésitez pas à laisser des commentaires ou des questions sur ce qui a été couvert ici.

Lecture connexe

• Le modèle de référentiel via la 8e lumière
• Le modèle de référentiel via MSDN
• Une implémentation du modèle de référentiel