Quelle est la différence entre le Mapper des Données, les Données de la Table de la Passerelle (Gateway), DAO (Data Access Object) d'un Référentiel et de modèles?
Je suis en train de balayer vers le haut sur mon modèle de conception de compétences, et je suis curieux de savoir quelles sont les différences entre ces modèles? Tous semblent comme ils sont de la même chose - encapsuler la logique de base de données pour une entité spécifique, de sorte que le code appelant n'a pas connaissance de la sous-couche de persistance. De mon mémoire de recherche tous généralement en œuvre de votre standard méthodes CRUD et d'abstraction de la base de données des informations spécifiques.
En dehors de conventions de nommage (par exemple CustomerMapper vs CustomerDAO vs CustomerGateway vs CustomerRepository), quelle est la différence, le cas échéant? Si il y a une différence, quand vous avez choisi l'un sur l'autre?
Dans le passé, je voudrais écrire un code semblable au suivant (simplifié, naturellement, je n'aurais pas l'habitude d'utiliser 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 ont un CustomerGateway
classe qui implémente la base de données spécifique de la logique pour toutes les méthodes. Parfois, je ne serait pas l'utilisation d'une interface et d'effectuer toutes les méthodes sur la CustomerGateway statique (je sais, je sais, ce qui la rend moins vérifiables) donc je peux l'appeler comme:
Customer cust = CustomerGateway.GetCustomerByID(42);
Ce qui semble être le même principe pour le Mapper des Données d'un Référentiel et de modèles; le pattern DAO (qui est la même chose que le Gateway, je pense?) semble également favoriser la base de données spécifiques à des passerelles.
Suis-je raté quelque chose? Il semble un peu bizarre d'avoir 3-4 façons différentes de faire la même chose exacte.
Vous devez vous connecter pour publier un commentaire.
Votre exemple de conditions; DataMapper, DAO, DataTableGateway et Référentiel, tous ont un objectif similaire (quand j'en utilise un, j'attends de récupérer un Client de l'objet), mais différent de l'intention/sens et résultant de la mise en œuvre.
Un Référentiel "agit comme une collection, à l'exception de plus élaborée interroger la capacité" [Evans, Domain Driven Design] et peut être considéré comme un "des objets dans la mémoire de façade" (Référentiel de discussion)
Un DataMapper "déplacer des données entre les objets et une base de données tout en gardant indépendamment les uns des autres et le mappeur de lui-même" (Fowler, PoEAA, Mappeur)
Un TableDataGateway est "une Passerelle (objet qui encapsule l'accès à un système externe ou de ressources) à une table de base de données. Un exemple les poignées de toutes les lignes dans la table" (Fowler, PoEAA, TableDataGateway)
Un DAO "sépare une ressource de données de l'interface du client à partir de ses données à des mécanismes d'accès /s'adapte spécifique de données de ressources d'accès de l'API pour un client générique interface" permettant "accès aux données des mécanismes visant à modifier indépendamment du code qui utilise les données" (Sun Blueprints)
Référentiel semble très générique, exposant sans aucune notion de base de données d'interaction.
Un DAO fournit une interface permettant de différents sous-jacente de la base de données des implémentations à être utilisé.
Un TableDataGateway est précisément une mince wrapper autour d'une table unique.
Un DataMapper agit comme un intermédiaire permettant le Modèle objet d'évoluer indépendamment de la base de données de la représentation (dans le temps).
Il y a une tendance dans les logiciels de conception du monde (au moins, je me sens tellement) pour inventer de nouveaux noms pour le bien-connu des choses anciennes et des modèles. Et quand nous avons un nouveau paradigme (qui peut-être quelque peu différente de celles déjà existantes choses), il vient habituellement avec un ensemble de nouveaux noms pour chaque niveau. Donc "Logique d'Entreprise" devient "Couche " Services" tout simplement parce que nous nous proposons de faire SOA, et DAO devient Référentiel juste parce que nous disons que nous ne DDD (et chacun de ces n'est pas réellement quelque chose de nouveau et unique à tous, mais encore une fois: de nouveaux noms déjà connus concepts réunis dans le même livre). Donc, je ne dis pas que tous ces nouveaux paradigmes et acronymes signifient EXACTEMENT la même chose, mais vous avez vraiment ne devrait pas être trop paranoïaque à ce sujet. La plupart de ces mêmes modèles, juste à partir de différentes familles.
Mapper des données vs Table Data Gateway
Pour rendre une longue histoire courte:
À la fin, les deux d'entre eux vont agir en tant que médiateur entre les objets de la mémoire et de la base de données.
Vous avez un bon point. Choisissez celui qui vous est le plus familier. Je tiens à souligner quelques choses qui peuvent aider à clarifier.
De la Table de la Passerelle de Données est utilisé principalement pour une seule table ou de la vue. Il contient tous les sélectionne, les insertions, mises à jour et les suppressions. Si le Client est une table ou une vue dans votre cas. Donc, un exemple d'un tableau de données de la passerelle poignées d'objet de toutes les lignes dans la table. Habituellement, cela est lié à un objet par table de base de données.
Tout de Mapper des Données est de plus en plus indépendante de toute logique de domaine et est moins couplée (bien que je crois qu'il n'y a couplage ou non de couplage). Il n'est qu'un intermédiaire de la couche à transférer les données entre les objets et une base de données tout en gardant indépendamment les uns des autres et le mappeur de lui-même.
Donc, généralement dans un mappeur, vous voyez des méthodes telles que insert, update, delete et dans le tableau de données de la passerelle, vous trouverez getcustomerbyId, getcustomerbyName, etc.
Objet de transfert de données se distingue de ces deux modèles, principalement parce qu'il est un modèle de distribution et non pas un modèle de source de données comme ci-dessus deux modèles. Utiliser principalement lorsque vous travaillez avec de l'interface à distance et la nécessité de faire vos appels moins bavard que chaque appel peut coûter cher. Donc, habituellement, la conception d'un DTO qui peut être sérialisé d'un fil qui peut transporter toutes les données vers le serveur pour l'application d'autres règles d'affaires ou de traitement.
Je ne suis pas très versé dans le modèle d'espace de stockage que je n'ai pas eu l'occasion de les utiliser jusqu'à maintenant, mais sera de regarder les autres réponses.
Ci-dessous est juste ma compréhension.
TableGateWay/RowDataGateWay:
Dans ce contexte, la Passerelle est en se référant à une mise en œuvre spécifique qui a chaque "objet de domaine" cartographie pour chaque "domaine objet de la passerelle". Par exemple, si nous avons Personne, alors nous aurons un PersonGateway pour stocker le domaine objet de la Personne à la base de données. Si nous avons de la Personne, un Employé, un Client, etc, nous aurons PersonGateway, EmployeeGateway, et CustomerGateway. Chaque passerelle sera spécifiques CRUD la fonction de cet objet, et il n'a rien à voir avec les autres de la passerelle. Il n'y a pas de code réutilisable/module 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 en comparaison avec Active record. Il les liens de votre modèle de domaine de schéma de base de données.
Référentiel/DataMapper/DAO: Ils sont la même chose. Ils se réfèrent tous à la couche de Persistance que le transfert de la base de données des entités du modèle de domaine. Contrairement à la passerelle, le Référentiel/DataMapper/DAO masquer la mise en œuvre. Vous ne savez pas si il y a un PersonGateway derrière Personne. Il peut, ou peut ne pas, vous n'avez pas de soins. Tout ce que vous savez est qu'il doit avoir des opérations CRUD pris en charge pour chaque objet du domaine. Il découpler la source de données et modèle de domaine.