Quale approccio in DataMapper Pattern è migliore per le tabelle multiple o congiunte?

Question

Quale approccio in DataMapper Pattern è migliore per le tabelle multiple o congiunte?

#1 da (5 voti)

8

Normalmente, un Data Mapper mappa i dati di una particolare tabella. (Teoricamente dovrebbe comunicare tra lo Storage e un Domain Object, ma non è possibile nel mio caso, quindi sto comunicando direttamente con le tabelle.)

Table1Mappper > Table1

Ma se quella tabella richiede che i dati vengano uniti da un'altra tabella, allora stai espandendo l'ambito del tuo Data Mapper che era solo supposto mappare da una tabella.

Table1Mapper > Table1 :inner-join: Table2

Non sarebbe meglio se Table2 avesse il suo mapper Table2Mapper per mappare i suoi dati?

Se pensi Yes , se vuoi mostrare un elenco di record da Table1Mapper e poi utilizzare Table2Mapper per ottenere quei dati che dovevano essere uniti, stai andando a eseguire una query in un ciclo, che non va bene neanche.

Che intuizioni su questo modo?

Un altro modo è quello di cambiare il tuo mapper per gestire le sotto tabelle?

class Table1Mapper {
    public main_table = 'table1';
    public sub_table1 = 'table2';
}

Penso che vada bene, ma solo fino a quando l'ambito dell'intero mappatore sta trattando una particolare entità nell'applicazione. Ad esempio post e post_author . Ma se l'ambito è diverso come post e gallery , quanto sopra non darà un mappatore dati ideale. Per illustrare questo

class PostMapper {
     public table_name = 'tbl_post';
     public gallery_table_name = 'tbl_gallery';
}

Non è corretto vero? Ma comunque vorrai prendere le gallerie di un post in una sola query, perché aggiungere un sovraccarico di query in un ciclo non è una buona soluzione.

Quale pensi che sia il modo giusto di risolverlo in DataMapper Pattern / o in qualsiasi altro pattern se ha un modo migliore di gestire tali casi?

design-patterns object-oriented-design

posta Starx 10.09.2015 - 11:36

fonte

1 risposta

Leggi altre domande sui tag design-patterns object-oriented-design

Autoreleasing di oggetti nei sistemi di conteggio di riferimento Quali sono i pattern più utilizzati per gestire molti parametri interconnessi?

score 5 · Answer 1

Per Data Mapper intendi quello descritto da Martin Fowler , giusto? È uno dei modelli di Pattern di origine dell'architettura dei dati. Altri sono:

Data Mapper si differenzia da altri modelli per quanto riguarda la relazione tra oggetti e tabelle. Sia i modelli di gateway dati che il modello di record attivo presuppongono quasi il mapping uno a uno dalle tabelle agli oggetti.

Diamo un'occhiata a un esempio:

table BANK_ACCOUNT
   ID

table BANK_ACCOUNT_BALANCE
   ID
   BANK_ACCOUNT_ID
   BALANCE_AMOUNT
   DATE

Gli oggetti del dominio sono quindi:

class BankAccount {
    long id;
}

class BankAccountBalance {
    long id;
    long bankAccountId;
    Decimal balanceAmount;
    Date date;
}

Come vedi la mappatura uno a uno tra classi e tabelle. Esistono anche due diversi gateway dati di tabella / riga o record attivi, uno per ogni tabella.

Al contrario, Data Mapper consente indiretto :

A layer of Mappers (473) that moves data between objects and a database while keeping them independent of each other and the mapper itself.

Quindi quando si utilizza Data Mapper gli oggetti possono essere diversi dalle tabelle del database. Sei libero di introdurre l'aggregazione, unirti ad altre tabelle, eseguire operazioni aritmetiche, introdurre gerarchie di ereditarietà. Quindi, rispondendo alla tua domanda - è perfettamente necessario unire due tabelle in Data Mapper fintanto che l'oggetto risultato è un oggetto dominio valido.

Nel nostro esempio potremmo avere:

class BankAccount {
    long id;
    Decimal latestBalance;
    Date latestBalanceDate;
}

come oggetto di dominio restituito da un singolo Data Mapper basato su JOIN e aggregazione.

Pertanto, Data Mapper è perfetto per rappresentare un modello di dominio non banale. Se il tuo modello di dominio è piuttosto semplice, potresti prendere in considerazione l'utilizzo di Pattern di registrazione attiva o Gateway dati.

Necessità di JOIN Il Data Mapper può talvolta (ma non deve) indicare che la classe di dominio è troppo complessa. Per favore controlla Principio di Responsabilità Unica , Principio di segregazione interfaccia .

Nelle classi di dominio di Domain-Driven Design (cioè restituite da Data Mapper) prendono la forma di entità o oggetti valore. DDD book descrive piuttosto bene di cosa dovrebbe consistere un'entità. Potresti voler controllare questo.

Inoltre DDD definisce Aggregati (molto ben descritto qui ). Sono spesso caricati insieme. Unire due tabelle potrebbe suggerire che ci sono due entità in un singolo aggregato.