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

Question

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, ils implémentent généralement vos méthodes CRUD standard et résument les détails spécifiques à la base de données.

Hormis 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 à celui-ci (simplifié, bien entendu - je n’utiliserais normalement pas les 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 disposez d'une classe CustomerGateway qui implémente la logique de base de données spécifique pour toutes les méthodes. Parfois, je ne voudrais pas utiliser une interface et rendre toutes les méthodes de CustomerGateway statiques (je sais, je le sais, cela le rend moins testable) afin 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.

Answer 1

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 référentiel "se comporte comme une collection, sauf qu'il dispose d'une fonctionnalité d'interrogation plus élaborée" [ Evans, Conception pilotée par le domaine ] et peut être considéré comme un " objet dans la mémoire de la façade " ( Discussion sur le référentiel )

Un 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 )

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 ainsi à "Mécanismes d'accès aux données à modifier indépendamment du code utilisant les données" ( Plans directeurs Sun )

Le référentiel semble très générique et n’expose 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 mince autour d'une seule table. Un DataMapper agit en tant qu'intermédiaire permettant à l'objet Modèle d'évoluer indépendamment de la représentation de la base de données (dans le temps).

Answer 2

Dans le monde de la conception de logiciels, on a tendance (du moins, à mon sens) à inventer de nouveaux noms pour de vieux objets et modèles 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. Donc, "Business Logic". devient " couche de services " juste parce que nous disons que nous faisons de la SOA, et DAO devient un référentiel simplement parce que nous disons de la DDD (et que chacune de ces choses n’est pas vraiment quelque chose de nouveau et d’unique, 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, venant de familles différentes.

Answer 3

Mappeur de données et passerelle de données de table Pour faire court:

le mappeur de données recevra l'objet de modèle de domaine (entité) en tant que paramètre et l'utilisera pour mettre en œuvre les opérations CRUD

la passerelle de données de table recevra tous les paramètres (en tant que primitives) pour les méthodes et ne saura rien de l'objet de modèle de domaine (Entity).

À la fin, ils joueront le rôle de médiateur entre les objets en mémoire et la base de données.

    

Answer 4

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 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.

Alors que Data Mapper est plus indépendant de toute logique de domaine et est moins couplé (bien que je pense qu'il existe un couplage ou non). 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.

Donc, 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. Vous devez donc généralement concevoir un DTO pouvant être sérialisé par fil qui puisse renvoyer toutes les données au serveur pour appliquer des règles commerciales 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.

Answer 5

Ci-dessous se trouve juste ma compréhension.

TableGateWay / RowDataGateWay : Dans ce contexte, Gateway fait référence à une implémentation spécifique comportant chaque "objet de domaine". mappage sur 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 en TableGateway, si 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.

Référentiel / DataMapper / DAO : c'est 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.