Quelle est la différence entre les modèles Data Mapper, Table Data Gateway (Gateway), Data Access Object (DAO) et Repository?
J'essaie de perfectionner mes compétences en modèles de conception et je suis curieux de savoir quelles sont les différences entre ces modèles. Ils semblent tous ressembler à la même chose: encapsuler la logique de la base de données pour une entité spécifique afin que le code appelant ne connaisse pas la couche de persistance sous-jacente. De ma brève recherche, tous implémentent généralement vos méthodes CRUD standard et résument les détails spécifiques à la base de données.
Outre les conventions de dénomination (par exemple, CustomerMapper vs. CustomerDAO vs. CustomerGateway vs. CustomerRepository), quelle est la différence, le cas échéant? S'il y a une différence, quand choisiriez-vous l'un par rapport à l'autre?
Dans le passé, j'écrivais un code similaire au suivant (simplifié, bien entendu, je n'utiliserais normalement pas de propriétés publiques):
public class Customer
{
public long ID;
public string FirstName;
public string LastName;
public string CompanyName;
}
public interface ICustomerGateway
{
IList<Customer> GetAll();
Customer GetCustomerByID(long id);
bool AddNewCustomer(Customer customer);
bool UpdateCustomer(Customer customer);
bool DeleteCustomer(long id);
}
et avoir une classe CustomerGateway qui implémente la logique de base de données spécifique pour toutes les méthodes. Parfois, je n'utilisais pas d'interface et ne rendais pas toutes les méthodes de CustomerGateway statiques (je sais, je sais, cela le rend moins testable) pour que je puisse l'appeler ainsi:
Customer cust = CustomerGateway.GetCustomerByID(42);
Cela semble être le même principe pour les modèles de mappeur de données et de référentiel; le modèle DAO (qui est la même chose que Gateway, je pense?) semble également encourager les passerelles spécifiques aux bases de données.
Est-ce que je manque quelque chose? Il semble un peu bizarre d’avoir 3 ou 4 façons différentes de faire exactement la même chose.
Votre exemple de termes; DataMapper, DAO, DataTableGateway et Repository ont tous un objectif similaire (lorsque j'en utilise un, je m'attends à récupérer un objet Customer), mais une intention/signification différente et une implémentation résultante.
Un Repository"agit comme une collection, sauf avec une capacité d'interrogation plus élaborée" [ Evans, Conception pilotée par le domaine ] et peut être considéré comme un "objet dans une façade en mémoire" ( Discussion sur le référentiel )
A DataMapper"déplace les données entre des objets et une base de données tout en les gardant indépendantes les unes des autres et du mappeur lui-même" ( Fowler, PoEAA, Mapper )
(TableDataGateway} _ is "une passerelle (objet encapsulant l'accès à un système ou une ressource externe) à une table de base de données. Une instance gère toutes les lignes de la table" ( Fowler, PoEAA, TableDataGateway )
Un DAO"sépare l'interface client d'une ressource de données de ses mécanismes d'accès aux données/adapte l'API d'accès d'une ressource de données spécifique à une interface client générique", ce qui permet à "les mécanismes d'accès aux données de changer indépendamment du code qui utilise les données " ( Sun Blueprints )
Le référentiel semble très générique, sans aucune notion d'interaction de base de données. Un DAO fournit une interface permettant d’utiliser différentes implémentations de bases de données sous-jacentes. Un TableDataGateway est spécifiquement un wrapper fin autour d’une seule table. Un DataMapper agit en tant qu'intermédiaire permettant à l'objet Model d'évoluer indépendamment de la représentation de la base de données (dans le temps).
Dans le monde de la conception de logiciels (du moins, à mon sens, au moins), on a tendance à inventer de nouveaux noms pour des choses et des modèles anciens bien connus. Et quand nous avons un nouveau paradigme (qui diffère peut-être légèrement des choses existantes), il vient généralement avec tout un ensemble de nouveaux noms pour chaque niveau. Ainsi, "Business Logic" devient "Services Layer" simplement parce que nous disons que nous faisons SOA, et DAO devient un référentiel simplement parce que nous disons que nous faisons DDD (et que chacun de ces éléments n'est pas réellement nouveau et unique, mais encore une fois: de nouveaux noms pour des concepts déjà connus réunis dans le même livre). Donc, je ne dis pas que tous ces paradigmes et acronymes modernes signifient EXACTEMENT la même chose, mais vous ne devriez vraiment pas être trop paranoïaque à ce sujet. La plupart du temps, ce sont les mêmes modèles, venant de familles différentes.
Data Mapper vs Table Data Gateway Pour faire une histoire longue:
À la fin, ils joueront tous les deux le rôle de médiateur entre les objets en mémoire et la base de données.
Vous avez un bon point. Choisissez celui que vous connaissez le mieux. J'aime souligner quelques points qui peuvent aider à clarifier.
La passerelle de données de table est principalement utilisée pour une seule table ou vue. Il contient tous les éléments sélectionnés, insérés, mis à jour et supprimés. Donc, le client est une table ou une vue dans votre cas. Ainsi, une instance d'un objet de passerelle de données de table gère toutes les lignes de la table. Généralement, cela est lié à un objet par table de base de données.
Tandis que Data Mapper est plus indépendant de toute logique de domaine et est moins couplé (bien que je pense qu'il y ait couplage ou non couplage). Il ne s'agit que d'une couche intermédiaire permettant de transférer les données entre des objets et une base de données tout en les maintenant indépendantes les unes des autres et du mappeur lui-même.
Ainsi, généralement dans un mappeur, vous voyez des méthodes comme insérer, mettre à jour, supprimer et dans la passerelle de données de table, vous trouverez getcustomerbyId, getcustomerbyName, etc.
L'objet de transfert de données diffère des deux modèles ci-dessus, principalement parce qu'il s'agit d'un modèle de distribution et non d'un modèle de source de données comme ci-dessus deux modèles. Utilisez-le principalement lorsque vous travaillez avec une interface distante et que vous devez rendre vos appels moins bavards, car chaque appel peut coûter cher. Par conséquent, concevez généralement un DTO pouvant être sérialisé sur un réseau filaire et pouvant renvoyer toutes les données au serveur afin de lui appliquer des règles ou un traitement supplémentaires.
Je ne connais pas bien le modèle de référentiel car je n’ai pas eu la chance de l’utiliser jusqu’à présent, mais j’examinerai d’autres réponses.
Ci-dessous est juste ma compréhension.
TableGateWay/RowDataGateWay : .__ Dans ce contexte, Gateway fait référence à une implémentation spécifique dont chaque "objet de domaine" est mappé à chaque "passerelle d'objet de domaine". Par exemple, si nous avons Person, nous aurons un PersonGateway pour stocker l'objet de domaine Person dans la base de données. Si nous avons une personne, un employé, un client, etc., nous aurons PersonGateway, EmployeeGateway et CustomerGateway. Chaque passerelle aura une fonction CRUD spécifique pour cet objet et cela n’a rien à voir avec une autre passerelle. Il n'y a pas de code/module réutilisable ici. La passerelle peut être divisée en RowDataGateway ou TableGateway, selon que vous transmettez un "id" ou un "objet". La passerelle est généralement comparée à l'enregistrement actif. Il relie votre modèle de domaine au schéma de base de données.
Repository/DataMapper/DAO : Ils sont la même chose. Ils font tous référence à la couche de persistance qui transfère des entités de base de données au modèle de domaine. Contrairement à la passerelle, le référentiel/DataMapper/DAO masque l’implémentation. Vous ne savez pas s'il y a un PersonGateway derrière Person. Cela peut ou peut ne pas vous intéresser. Tout ce que vous savez, c'est que les opérations CRUD doivent être prises en charge pour chaque objet de domaine. Il découple la source de données et le modèle de domaine.