"Mapper" è un modello di progettazione valido o è una variante del modello "Fabbrica"?

Question

"Mapper" è un modello di progettazione valido o è una variante del modello "Fabbrica"?

#1 da (22 voti)
#2 da (8 voti)
#3 da (4 voti)
#4 da (3 voti)
#5 da (1 voti)
#6 da (0 voti)

33

Un pattern comune che vedo è quello che è noto come Mapper pattern (da non confondere con DataMapper che è tutt'altra cosa), che prende come argomento una sorta di fonte di dati "grezza" (es. un ADO .NET DataReader o DataSet ) e associa i campi alle proprietà su un oggetto business / dominio. Esempio:

class PersonMapper
{
    public Person Map(DataSet ds)
    {
        Person p = new Person();
        p.FirstName = ds.Tables[0].Rows[0]["FirstName"].ToString();
        // other properties...
        return p;
    }
}

L'idea è il tuo Gateway / DAO / Repository / ecc. chiamerà nel Mapper prima che ritorni, in modo da ottenere un oggetto business ricco rispetto al contenitore dati sottostante.

Tuttavia, questo sembra essere correlato, se non identico, al modello Factory (nel linguaggio DDD, comunque), che costruisce e restituisce un oggetto dominio. Wikipedia dice questo: la fabbrica DDD:

Factory: methods for creating domain objects should delegate to a specialized Factory object such that alternative implementations may be easily interchanged.

Da quella citazione l'unica differenza che potrei pensare è che la Factory in stile DDD potrebbe essere parametrizzata in modo da poter restituire un tipo di oggetto specializzato se necessario (ad esempio BusinessCustomer o ResidentialCustomer) mentre il "Mapper" è impostato per una classe specifica e solo fa la traduzione.

Quindi c'è una differenza tra questi due modelli o sono essenzialmente la stessa cosa con nomi diversi?

design-patterns

posta Wayne Molina 02.11.2011 - 16:08

fonte

6 risposte

8

L'unica cosa comune su Mapper, Builder e Factory è che forniscono un "prodotto costruito" - e l'istanza di un oggetto di un tipo. Per evitare qualsiasi confusione, mi riferisco alle seguenti discussioni per la loro rispettiva definizione.

Mapper - vicino a quanto spiegato qui: link . Questo non è esattamente lo stesso di sopra - ma più vicino ho trovato su mapper.
Builder - come definito qui: link
Factory - è definito qui: link

Il mapper è essenzialmente un costruttore al suo interno. Supponiamo per un po ', se non si dispone di un mapper - Quando si ha comunque bisogno di molti set di parametri, sono tutti argomenti sul costruttore. Ora che le cose si evolvono, alcune applicazioni non sono a conoscenza di attributi aggiuntivi che devono essere sottoposti al costruttore, dove uno lo calcola o utilizza l'impostazione predefinita. La cosa fondamentale è che il mappatore può farlo per te - e sarebbe più utile se questo avesse un collegamento con oggetti esterni per decidere un tale algoritmo per la costruzione.

Il Builder è molto diverso dal mapper. Un costruttore è essenziale quando un oggetto completo viene composto utilizzando molte parti dell'oggetto. È un po 'come assemblare gli oggetti unendo molte parti. Anche l'inizializzazione dei singoli oggetti delle parti è correlata all'esistenza di altre parti.

Gli schemi di fabbrica sembrano molto semplici all'inizio. Restituisce un oggetto di nuova costruzione. Se qualche costruttore ordinario può darmi un'istanza completamente funzionale usando un operatore come new ()? perché avrei bisogno di una fabbrica che mi dia gli stessi risultati?

Tuttavia, l'utilizzo del pattern factory è in genere molto specifico; sebbene il più spesso, non visualizzato in letteratura dove questo è applicato. Di solito, un'applicazione crea una fabbrica che è condivisa con vari oggetti che devono creare tali oggetti di prodotto durante l'esecuzione. Quando vengono creati molti di questi prodotti, il metodo Factory consente la creazione di oggetti basati su determinate policy , ad esempio, si può forzare un determinato template che viene usato dal metodo factory quando tutti gli oggetti sono creati. Questo non è né come un metodo costruttore; qui il prodotto è solo uno (e indipendente). Anche questo non è come un mappatore; qui i dati esterni impostati per creare oggetti secondo il client sono in realtà minimi. Il modello factory fornisce realmente (come suggerisce il nome) oggetti di prodotto sempre simili!

Dipan.

risposta data 02.11.2011 - 18:53

fonte

4

Mentre guardo le risposte, vedo che gli intervistati forniscono risposte semanticamente sbagliate. Penso che sia perché sei troppo concentrato sulla domanda, che è focalizzata su come il mapper è correlato alla fabbrica o al costruttore.

Quando in realtà Mapper NON è simile alla fabbrica o al costruttore. Il mapper è molto simile al pattern adattatore (che usa il linguaggio di GoF). Il modello dell'adattatore fornisce funzionalità per convertire una rappresentazione in un'altra. L'OP si riferiva al DataSet e al DataReader in ADO.NET-- e che ne dici di SqlDataAdapter? La risposta è nel nome. Mapper è un nuovo nome per qualcosa che i programmatori più vecchi conoscono da molto tempo: gli adattatori.

Il mappatore converte una rappresentazione in un'altra: la stessa definizione del modello dell'adattatore.

risposta data 24.08.2016 - 19:27

fonte

3

la risposta alla tua domanda: "Mapper" è un modello di progettazione valido? è sì. Il pattern Mapper è anche conosciuto come Translator Pattern ed è un pattern documentato: link

risposta data 28.07.2012 - 10:13

fonte

1

Ciò che stai facendo qui è in realtà una sorta di conversione di tipo (converti i tuoi dati grezzi in un oggetto business). Puoi usare il modello di fabbrica per fare esattamente questo (cioè digitare conversioni), quindi sì, in un certo senso, la tua classe è una fabbrica (anche se userei un Fabbrica statica per questo).

risposta data 02.11.2011 - 17:07

fonte

0

I costruttori racchiudono una complessa logica aziendale per costruire un oggetto. Mapper d'altra parte dovrebbe semplicemente copiare i campi da uno all'altro.

Ad esempio mappa dall'oggetto Dipendente del database all'oggetto Dipendente dominio, mappa dall'oggetto Dipendente dominio al contratto client.

I costruttori d'altra parte ospitano più decisioni aziendali per creare un oggetto. Dal punto di vista della singola responsabilità, ciò ha senso.

risposta data 07.07.2013 - 07:35

fonte

Leggi altre domande sui tag design-patterns

Perché i programmi utilizzano stack di chiamate, se le chiamate di funzioni nidificate possono essere inline? Quando e perché dovresti usare void (invece di ad esempio bool / int)

score 22 · Accepted Answer

Anche se è la prima volta che sento il pattern di Mapper, per me sembra più il pattern Builder che Factory.

Nel pattern Factory incapsula la logica per creare oggetti di un certo numero di classi correlate. L'esempio principale potrebbe essere una situazione in cui è necessario creare un oggetto di una particolare sottoclasse di una classe di base astratta in base ad alcuni parametri. Quindi una Factory restituisce sempre un puntatore o un riferimento alla classe base, ma in realtà crea un oggetto della classe derivata appropriata in base ai parametri che gli vengono assegnati.

Al contrario, una classe Builder crea sempre oggetti della stessa classe. Lo useresti se la creazione di un oggetto è complicata, e. g. il suo costruttore prende molti argomenti, non tutti possono essere disponibili all'istante. Quindi un oggetto costruttore può essere un luogo che memorizza i valori per gli argomenti del costruttore fino a quando non li hai tutti e sei pronto per creare il "prodotto", oppure può fornire valori predefiniti ragionevoli e ti consente solo di specificare gli argomenti di cui hai bisogno modificare. Un tipico caso d'uso per il pattern Builder è la creazione di oggetti che potrebbero essere necessari in un test unitario, per evitare di ingombrare il codice di test con tutta la logica di creazione.

Per me un Mapper suona come una variante di un Builder, in cui i parametri del costruttore si presentano sotto forma di un record del database o di qualche altra struttura di dati "grezza".