Quelle est la différence entre les modèles Data Mapper, Table Data Gateway (passerelle), Data Access Object (DAO) et Repository?

J'essaie de rafraîchir mes compétences en matière de conception de modèles, et je suis curieux de savoir quelles sont les différences entre ces modèles? Tous semblent être la même chose - encapsuler la logique de la base de données pour une entité spécifique afin que le code appelant n'ait aucune connaissance de 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 plutôt que l'autre?

Dans le passé, j'écrivais un code similaire au suivant (simplifié, naturellement - 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 CustomerGatewayclasse qui implémente la logique de base de données spécifique pour toutes les méthodes. Parfois, je n'utiliserais pas une interface et je ne rendrais pas toutes les méthodes de CustomerGateway statiques (je sais, je sais, cela le rend moins testable) afin que je puisse l'appeler comme:

Customer cust = CustomerGateway.GetCustomerByID(42);

Cela semble être le même principe pour les modèles Data Mapper et Repository; 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? Cela semble un peu étrange d'avoir 3-4 façons différentes de faire exactement la même chose.

Vos exemples 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 / une signification différente et une implémentation résultante.

Un référentiel "agit comme une collection, sauf avec une capacité d'interrogation plus élaborée" [ Evans, Domain Driven Design ] et peut être considéré comme une "façade d'objets en mémoire" ( discussion sur le référentiel )

Un DataMapper "déplace les données entre les objets et une base de données tout en les gardant indépendants les uns des autres et du mappeur lui-même" ( Fowler, PoEAA, Mapper )

Un TableDataGateway est "une passerelle (objet qui encapsule 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" permettant "aux 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, n'exposant aucune notion d'interaction avec la base de données. Un DAO fournit une interface permettant d'utiliser différentes implémentations de base de données sous-jacentes. Un TableDataGateway est spécifiquement un wrapper mince autour d'une seule table. Un DataMapper agit comme un intermédiaire permettant à l'objet Model d'évoluer indépendamment de la représentation de la base de données (dans le temps).

Il y a une tendance dans le monde de la conception de logiciels (du moins, je le sens) à inventer de nouveaux noms pour des choses et des modèles anciens bien connus. Et lorsque nous avons un nouveau paradigme (qui diffère peut-être légèrement des choses déjà existantes), il est généralement accompagné d'un ensemble de nouveaux noms pour chaque niveau. Donc "Business Logic" devient "Services Layer" simplement parce que nous disons que nous faisons SOA, et DAO devient Repository simplement parce que nous disons que nous faisons DDD (et chacun de ces éléments n'est pas en fait quelque chose de nouveau et d'unique du tout, mais encore une fois: de nouveaux noms pour des concepts déjà connus rassemblés 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, juste de familles différentes.

Data Mapper vs Table Data Gateway Pour faire une histoire courte:

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 toutes les sélections, inserts, mises à jour et suppressions. Le client est donc 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. Cela est généralement lié à un objet par table de base de données.

Alors que Data Mapper est plus indépendant de toute logique de domaine et est moins couplé (même si je pense qu'il y a couplage ou non). Il s'agit simplement d'une couche intermédiaire pour transférer les données entre les objets et une base de données tout en les gardant indépendants les uns des autres et du mappeur lui-même.

Ainsi, généralement dans un mappeur, vous voyez des méthodes telles que 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. Concevez donc généralement un DTO qui peut être sérialisé sur un câble qui peut transporter toutes les données vers le serveur pour appliquer d'autres règles métier ou un traitement.

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 je vais regarder les 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 qui a chaque «objet de domaine» 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, dépend si vous passez un "id" ou un "objet". La passerelle est généralement comparée à l'enregistrement actif. Il lie votre modèle de domaine au schéma de base de données.

Repository / DataMapper / DAO : C'est la même chose. Ils font tous référence à la couche de persistance qui transfère les entités de base de données vers le 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 non, vous ne vous en souciez pas. Tout ce que vous savez, c'est que les opérations CRUD doivent être prises en charge pour chaque objet de domaine. Il dissocie la source de données et le modèle de domaine.