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.
la source
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.
la source
Data Mapper vs Table Data Gateway Pour faire une histoire courte:
En fin de compte, les deux joueront le rôle de médiateur entre les objets en mémoire et la base de données.
la source
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.
la source
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.
la source