Best practice per il mapping di DTO all'oggetto dominio?

Question

Ho visto un sacco di domande relative alla mappatura di DTO per Domain Objects, ma non ho sentito che hanno risposto alla mia domanda. Ho usato molti metodi prima e ho le mie opinioni, ma sto cercando qualcosa di un po 'più concreto.

la situazione:

Abbiamo molti oggetti di dominio. Stiamo utilizzando un modello CSLA in modo che i nostri oggetti di dominio possano essere piuttosto complessi e che contengano il proprio accesso ai dati. Non vuoi passare questi in giro sul filo. Scriveremo alcuni nuovi servizi che restituiranno i dati in numerosi formati (.Net, JSON, ecc.). Per questo (e altri motivi) stiamo anche creando un oggetto di trasferimento dati snello da passare sul filo.

La mia domanda è come deve essere collegato l'oggetto DTO e Dominio?

La mia prima reazione è usare un Fowler, DTO pattern-type solution. Ho visto questo fatto molte volte e mi sembra giusto. L'oggetto dominio non contiene riferimenti al DTO. Un'entità esterna (un "mapper" o un "assemblatore") viene chiamata per creare un DTO da un Oggetto Dominio. Normalmente c'è un ORM sul lato dell'oggetto dominio. Lo svantaggio di questo è che il "mapper" tende a diventare estremamente complesso per qualsiasi situazione reale e può essere molto fragile.

Un'altra idea è che l'oggetto dominio "contenga" il DTO, poiché è solo un oggetto dati snello. Le proprietà dell'oggetto dominio farebbero riferimento internamente alle proprietà DTO e potrebbero semplicemente restituire il DTO, se richiesto. Non vedo problemi con questo, ma mi sembra sbagliato. Ho visto alcuni articoli in cui le persone che utilizzano NHibernate sembravano utilizzare questo metodo.

Ci sono altri modi? Vale la pena usare uno dei modi sopra indicati? Se sì o no, perché?

Grazie per eventuali approfondimenti in anticipo.

Answer 1

Un vantaggio di disporre di un mapper che si trova tra il dominio e il DTO non è così apparente quando si supporta solo una singola mappatura, ma all'aumentare del numero di mapping, avere quel codice isolato dal dominio aiuta a mantenere il dominio più semplice e più snello. Non ingombrerai il tuo dominio con un sacco di peso in più.

Personalmente, cerco di mantenere la mappatura fuori dalle mie entità di dominio e di mettere la responsabilità in quello che chiamo "Livello Manager/Servizio". Questo è un livello che si trova tra l'applicazione e il respository (i) e fornisce la logica di business come il coordinamento del flusso di lavoro (se si modifica A, potrebbe essere necessario modificare anche B in modo che il servizio A funzioni con il servizio B).

Se avessi molti formati finali possibili, potrei cercare di creare un formattatore plug-in che possa usare il pattern Visitor, ad esempio per trasformare le mie entità, ma non ho ancora trovato il bisogno di qualcosa di così complesso.

Answer 2

È possibile utilizzare un automapper come the one written by Jimmy Bogard che non ha alcuna connessione tra gli oggetti e fa affidamento sulle convenzioni di denominazione rispettate.

Answer 3

Si può anche provare Otis, un mappatore Object-to-object. I concetti sono simili alla mappatura di NHibernate (attributo o XML).

http://code.google.com/p/otis-lib/wiki/GettingStarted

Answer 4

Un'altra possibile soluzione: http://glue.codeplex.com.

Caratteristiche:

• bidirezionale mappatura
• mappatura automatica
• Mapping tra i diversi tipi
• mappatura nidificati e l'appiattimento
• liste e array
• di verifica delle relazioni
• Testing i mappatura
• Proprietà, campi e metodi

Answer 5

Usiamo modelli T4 per creare le classi di mappatura.

Pro's - codice leggibile dall'uomo disponibile in fase di compilazione, più veloce di un programma di analisi runtime. Controllo al 100% del codice (può utilizzare metodi parziali/modello di template per estendere funzionalità su base ad-hoc)

Con - escludendo determinate proprietà, raccolte di oggetti di dominio ecc., Imparando la sintassi T4.

Answer 6

Posso suggerire uno strumento che ho creato ed è open source ospitato su CodePlex: EntitiesToDTOs.

La mappatura dal DTO all'entità e viceversa è implementata mediante metodi di estensione, questi compongono il lato Assemblatore di ciascuna estremità.

si finisce con il codice come:

Foo entity = new Foo(); 
FooDTO dto = entity.ToDTO(); 
entity = dto.ToEntity(); 

List<Foo> entityList = new List<Foo>(); 
List<FooDTO> dtoList = entityList.ToDTOs(); 
entityList = dtoList.ToEntities(); 

Answer 7

Come vedi ad implementare un costruttore all'interno della classe DTO che prende come parametro un oggetto di dominio?

dire ... Qualcosa di simile

class DTO { 

    // attributes 

    public DTO (DomainObject domainObject) { 
      this.prop = domainObject.getProp(); 
    } 

    // methods 
} 

Answer 8

Perché non possiamo fare in questo modo?

class UserDTO { 
} 

class AdminDTO { 
} 

class DomainObject { 

// attributes 
public DomainObject(DTO dto) { 
     this.dto = dto; 
}  

// methods 
public function isActive() { 
     return (this.dto.getStatus() == 'ACTIVE') 
} 

public function isModeratorAdmin() { 
     return (this.dto.getAdminRole() == 'moderator') 
} 

} 


userdto = new UserDTO(); 
userdto.setStatus('ACTIVE'); 

obj = new DomainObject(userdto) 
if(obj.isActive()) { 
    //print active 
} 

admindto = new AdminDTO(); 
admindto.setAdminRole('moderator'); 

obj = new DomainObject(admindto) 
if(obj.isModeratorAdmin()) { 
    //print some thing 
} 

@FrederikPrijck (o) qualcuno: Si prega di suggerire. Nell'esempio sopra DomainObject dipende da DTO. In questo modo posso evitare che il codice esegua il mapping di dto < -> domainobject.

o la classe DomainObject può estendere la classe DTO?