Où doivent résider les conditions de requêtes complexes : mappeur de données ou couche de service ?

Le mappeur de données ou la couche de service doit-il gérer des conditions de requête complexes ?

Cette question se pose dans le contexte de requêtes complexes impliquant plusieurs conditions. Le modèle Data Mapper, conçu pour faciliter les interactions avec les bases de données, fournit généralement une méthode générique get() pour récupérer des données en fonction de conditions spécifiées. Cependant, dans les scénarios où des requêtes plus complexes sont nécessaires, des problèmes surviennent quant à la gestion appropriée de ces conditions.

Une approche consiste à étendre la méthode get() du Data Mapper pour accepter plusieurs conditions. Cela permet à la couche service d’appeler directement la méthode étendue, réduisant ainsi son rôle à un simple intermédiaire. À l’inverse, l’approche alternative permet à la couche de service d’analyser les conditions avant d’invoquer la méthode générique get() avec plusieurs conditions passées. Cela déplace la logique conditionnelle vers la couche de service, laissant le Data Mapper avec une implémentation plus simple.

Bien que l'approche de la couche de service garantisse le confinement de la logique de domaine dans la couche de modèle, elle compromet sans doute l'objectif principal du Data Mapper. modèle, qui consiste à gérer les interactions avec la base de données. Certains soutiennent que le mappeur doit rester simple, en se concentrant sur la récupération et le stockage des données, tandis que la couche de service assume la responsabilité de gérer les requêtes complexes et de garantir le respect des règles métier.

Alternativement, l'approche Data Mapper maintient la séparation des préoccupations, le mappeur gérant la manipulation des données et la couche de service responsable des tâches de niveau supérieur. Le mappeur peut être étendu pour inclure des méthodes adaptées pour gérer des combinaisons spécifiques de conditions, telles que getByAuthorAndPublisher(). Cette approche réduit le rôle de la couche de service à un coordinateur, déléguant une grande partie de la logique conditionnelle aux objets du domaine eux-mêmes.

En fin de compte, le choix entre ces approches dépend de facteurs tels que la complexité de l'application, le niveau souhaité de granularité dans la récupération des données et les préférences de l'équipe. Il n'existe pas de solution universellement acceptée, mais comprendre les compromis et prendre en compte le contexte de l'application aidera les développeurs à déterminer l'approche la plus appropriée pour leur cas d'utilisation spécifique.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!