passerelle de données de table et objet d'accès aux données différence architecturale

Question

Quelqu'un peut-il décrire la principale différence entre la passerelle de données de table (TDG) et l'objet d'accès aux données (DAO)?

TDG peut fonctionner avec toute ligne de cette table, mais si et DAO (DAO peut enregistrer, supprimer l'objet spécifié, mais peut aussi effectuer des opérations sur table entière)

Cordialement

Answer 1

Selon moi, la principale La différence est que TDG est centré sur la base de données (persistance), alors que DAO est centré sur l'instance métier/objet. TDG agit comme une façade (en quelque sorte) à la table de base de données - et est centrée sur la table (changez la table et vous changeriez le TDG).

Les DAO sont une vue abstraite qui représente généralement une instance spécifique d'un objet (pas toute la table, dans une perspective centrée sur une table - en fait, ils ne sont pas du tout centrés sur la persistance); Les DAO sont souvent conçus autour de concepts d'entreprise. TDG serait utile dans les situations où vous avez simplement besoin de construire une couche d'accès au-dessus d'une base de données - où le projet était tout sur la base de données (y accéder pour d'autres applications, par exemple un système hérité). Les DAO sont utilisés dans des situations plus «normales» où vous construisez une nouvelle solution orientée métier/logique à partir de zéro.

TDG Exemple (code pseudo)

Votre point de départ serait la base de données, par exemple: une table avec 3 lignes de données:

ContactsTable 
-------------------- 
Id | Name | Ph 
-------------------- 
01 | Bob | 192837 
02 | Joe | 564738 
03 | Ali | 483957 

L'étape suivante consiste à construire une couche du code qui gère l'accès physique aux données, et les données que vous retournez ne seraient ni plus ni moins que ce que la table offre. Si vous avez plusieurs tables, ils seront exposés séparément (je pense - je dois vérifier). En tant que consommateur de données, vous devez joindre des éléments dans votre logique (dans le code en dehors du TDG lui-même).

Comment votre code renvoie les données est en grande partie à vous - vous pouvez même utiliser un objet:

Class ContactTableRecord 
[ 
    Id 
    Name 
    Ph 
] 

Alors maintenant, vous avez une représentation des données dans le code; Votre application peut utiliser les données comme bon lui semble. Mais si la structure de la base de données change, vous devrez également modifier la couche de code pour correspondre - dans ce cas, la classe ContactTableRecord. Ainsi, les décisions de conception sur la manière dont les données sont exposées sont déterminées par la source de données.

DAO Exemple (code pseudo)

D'abord, vous souhaitez concevoir votre système autour de concepts - comme clients, les licences, les permis, les achats, les avenants, les lieux et ainsi de suite; vous modéliseriez alors (probablement) les relations entre ceux-ci. Disons que nous avons eu quelques cours dans notre logique métier de base que nous avons définis comme:

Class Customer 
[ 
    Id 
    Name 
    Ph 
    Purchases 
    ListAllPurchases() 
    SendInvoice() 
] 

Class Purchase 
[ 
    Id 
    ItemDescription 
    Customer 
    DateOfPurchase 
] 

Jusqu'à ce stade, nous avons pas accédé à toutes les données, nous pourrions savoir même pas ce que notre source de données va être. Si nous pensons en avance, nous allons résumer l'accès aux données en utilisant Dependancy Inversion (DI).

L'interface entre le BL et le DAL est d'importance centrale pour DI; nous pourrions spécifier une interface qui comprenait quelque chose comme ceci:

GetPurchaseDetails() - returns a PurchaseDetails object 

L'objet PurchaseDetails que nous avons défini, que nous avons l'intention de passer entre les BL et DAL - ou entre notre application et une autre application est un OTI - c'est un Représentation des données qui composent l'achat et le client. Parce que son centre de gravité est le BL, il n'est pas limité par la structure de la base de données (en fait, nous n'y sommes même pas encore parvenus - nous n'avons pas besoin que le DAO existe).

// This is our DAO: 
Class PurchaseDetails 
[ 
    CustomerId 
    Name 
    Ph 
    PurchaseId 
    ItemDescription 
    DateOfPurchase 
] 

Pour un autre avis voir: Table Data Gateway vs. Data Access Object