Plain Old CLR oggetto vs Data Transfer Object

Question

POCO = Plain Old CLR (o meglio: Class) oggetto

DTO = Data Transfer Object

In questo href="http://rlacovara.blogspot.com/2009/03/what-is-difference-between-dto-and-poco.html" c'è una differenza, ma francamente la maggior parte dei blog ho letto descrivere POCO nel modo DTO è definito:. DTOs sono semplici contenitori di dati utilizzati per lo spostamento di dati tra i livelli di un'applicazione

Are POCO e DTO la stessa cosa?

Answer 1

A POCO segue le regole della programmazione orientata agli oggetti. Si dovrebbe (ma non deve) avere stato e comportamento. POCO viene da POJO, coniato da Martin Fowler [ aneddoto qui ]. Ha usato il termine POJO come un modo per renderlo più sexy di respingere le implementazioni quadro pesante EJB. POCO deve essere utilizzato nello stesso contesto in .Net. Non lasciate che i quadri dettare il design del vostro oggetto.

unico scopo di un DTO è quello di trasferire lo stato, e non dovrebbe avere un comportamento. Vedere spiegazione di Martin Fowler di un DTO per un esempio di utilizzo di questo modello.

Ecco la differenza: POCO descrive un approccio alla programmazione (buon vecchio stile programmazione orientata agli oggetti), in cui DTO è un modello che viene utilizzato per "trasferimento dati" utilizzando oggetti.

Mentre si può trattare come pocos DTOs, si corre il rischio di creare un modello di dominio anemico se si fa così. Inoltre, c'è una mancata corrispondenza nella struttura, dal momento che DTOs dovrebbero essere progettati per trasferire i dati, non rappresentare la vera struttura del dominio aziendale. Il risultato di ciò è che DTOs tendono ad essere più piatta del vostro dominio effettivo.

In un dominio di qualsiasi complessità ragionevole, sei quasi sempre meglio creare dominio separato pocos e traducendole a DTOS. DDD (dominio design driven) definisce la anticorruzione strato (altro link qui , ma cosa migliore da fare è acquistare il libro ), che è una buona struttura che rende la segregazione chiara.

Answer 2

E 'probabilmente ridondante per me di contribuire da quando ho già espresso la mia posizione nel mio articolo del blog, ma l'ultimo paragrafo dello stesso articolo tipo di somme cose:

Quindi, in conclusione, imparare ad amare la POCO, e assicuratevi di non diffondere alcuna informazione sbagliata sul fatto che sia la stessa cosa di un DTO. DTOs sono semplici contenitori di dati utilizzati per lo spostamento di dati tra i livelli di un'applicazione. Pocos sono pieni oggetti di business a tutti gli effetti con quella esigenza che essi sono Persistenza Ignorant (senza get o risparmiare metodi). Infine, se non avete ancora controllato il libro di Jimmy Nilsson, raccoglierlo dal tuo stack universitari locali. Ha esempi in C # ed è un grande letto.

A proposito, Patrick ho letto il POCO come un articolo Stile di vita, e Sono completamente d'accordo, che è un articolo fantastico. In realtà è una sezione del libro di Jimmy Nilsson che ho raccomandato. Non avevo idea che fosse disponibile on-line. Il suo libro è davvero la migliore fonte di informazioni che ho trovato su / DTO / Repository / e di altre pratiche di sviluppo DDD POCO.

Answer 3

POCO è semplicemente un oggetto che non prende una dipendenza su un quadro esterno. È chiaro.

Se un POCO ha un comportamento o no è irrilevante.

Un DTO può essere POCO come può un oggetto di dominio (che sarebbe normalmente essere ricco di comportamento).

In genere DTOs sono più propensi a prendere le dipendenze sui quadri esterni (ad es. Gli attributi) per scopi di serializzazione come tipicamente in uscita al confine di un sistema.

Nelle architetture tipiche stile cipolla (spesso usato all'interno di un approccio ampiamente DDD) lo strato dominio è posto al centro e quindi gli oggetti non deve, a questo punto, avere dipendenze esterne di tale strato.

Answer 4

ho scritto un articolo per questo argomento: DTO vs valore dell'oggetto vs POCO .

In breve:

• DTO! = Valore oggetto
• DTO ⊂ POCO
• valore dell'oggetto ⊂ POCO

Answer 5

Credo che un DTO può essere un POCO. DTO è più circa l'uso dell'oggetto, mentre POCO è più dello stile dell'oggetto (disaccoppiato dal concetti architettonici).

Un esempio in cui un POCO è qualcosa di diverso rispetto a DTO è quando si sta parlando di POCO all'interno del vostro modello logico modello di dominio / incassi, che è una rappresentazione OO bella del dominio del problema. È possibile utilizzare il POCO del tutto l'intera applicazione, ma questo potrebbe avere qualche effetto collaterale indesiderato tale conoscenza perdite. DTO sono per esempio utilizzati dallo strato di servizio che l'utente comunica con, il DTO sono rappresentazione piatta dei dati, e sono utilizzati solo per fornire l'interfaccia utente con i dati, e comunicare modifiche indietro al livello di servizio. Il livello di servizio è responsabile della mappatura del DTO entrambi i modi agli oggetti di dominio POCO.

Aggiorna Martin Fowler detto che questo approccio è una strada pesante da prendere, e dovrebbe essere presa soltanto se non c'è corrispondenza significativa tra lo strato di dominio e l'interfaccia utente.

Answer 6

Un caso d'uso primario per un DTO è nella restituzione dei dati da un servizio Web. In questo caso, POCO e DTO sono equivalenti. Qualsiasi comportamento nel POCO sarebbe stato rimosso quando viene restituito da un servizio Web, quindi in realtà non importa se sia o non ha un comportamento.

Answer 7

qui è la regola generale: DTO == male e indicatore del software over-ingegnerizzato. POCO == buona. modelli di 'impresa' hanno distrutto il cervello di un sacco di persone nel mondo Java EE. si prega di non ripetere l'errore nella terra di .NET.

Answer 8

classi DTO sono utilizzati per serializzare i dati / deserializzare provenienti da fonti diverse. Quando si desidera deserializzare un oggetto da una fonte, non importa quale fonte esterna che è: il servizio, il file, database, ecc si può essere desidera utilizzare solo una parte di questo, ma si desidera un modo semplice per deserializzare i dati a un oggetto. dopo che si copiano i dati al XModel che si desidera utilizzare. Un serializer è una bella tecnologia per caricare oggetti DTO. Perché? è necessario solo una funzione per caricare (deserialize) l'oggetto.

Answer 9

TL; DR:

Un DTO descrive il modello di trasferimento dello Stato. A POCO non descrive nulla. È un altro modo di dire "oggetto" in OOP. Viene da POJO (Java), coniato da Martin Fowler che letteralmente lo descrive come un nome più elaborato di 'oggetto' in quanto 'oggetto' non è molto sexy.

Un DTO è un modello oggetto utilizzato per trasferire stato tra strati di preoccupazione. Essi possono avere comportamenti (cioè può tecnicamente essere un poco) finché tale comportamento non mutare lo stato. Ad esempio, può avere un metodo che si serializza.

A POCO è un oggetto semplice, ma cosa si intende per 'normale' è che non è speciale. Significa solo che si tratta di un oggetto CLR senza il modello implicito ad esso. Un termine generico. Non è fatto per lavorare con qualche altro quadro. Così, se il POCO ha [JsonProperty] o decorazioni EF in tutto le sue proprietà, per esempio, allora direi che non è una POCO.

Ecco alcuni esempi di diversi tipi di modelli di oggetti per confrontare:

• Visualizza Modello : utilizzato per modellare i dati per una vista. Di solito ha le annotazioni di dati per assistere vincolante e convalida. In MVVM, agisce anche come un controller. E 'più di un DTO
• Valore oggetto : utilizzata per rappresentare i valori
• Aggregate Root : utilizzato per gestire lo stato e invarianti
• Gestori : consente di rispondere a un evento / messaggio
• Attributi : utilizzato come decorazioni per affrontare le preoccupazioni trasversali
• servizio : utilizzato per eseguire compiti complessi
• Regolatore : utilizzato per controllare il flusso di richieste e risposte
• Fabbrica : consente di configurare e / o assemblare oggetti complessi da utilizzare quando un costruttore non è abbastanza buono. Utilizzato anche per prendere decisioni su cui devono essere creati a runtime gli oggetti.
• Repository / DAO : utilizzata per accedere ai dati

Si tratta di oggetti tutti solo, a meno di notare che la maggior parte di loro sono generalmente legati a un modello. Così si potrebbe chiamarli "oggetti" o si potrebbe essere più preciso circa il suo intento e lo chiamano da quello che è. Questo è anche il motivo per cui abbiamo modelli di progettazione; per descrivere concetti complessi in alcune opere. DTO è un modello. radice di aggregazione è un modello, Vista modello è un modello (ad esempio MVC e MVVM). POCO non è un modello.

A POCO non descrive un modello. È solo un modo diverso di riferirsi a classi / oggetti OOP. Pensate a come un concetto astratto; essi possono essere riferisce a qualsiasi cosa. IMO, c'è una relazione unidirezionale però, perché una volta che un oggetto raggiunge il punto in cui può servire solo scopo modo pulito, non è più a Poco. Ad esempio, una volta si contrassegna la vostra classe con decorazioni per farlo funzionare con un quadro di riferimento, non è più un POCO è. Pertanto:

• Un DTO è un POCO
• A POCO non è un DTO
• una vista del modello è un POCO
• A POCO non è una vista del modello

Il punto nel fare una distinzione tra i due è di mantenere modelli chiara e coerente nel tentativo di non attraversare preoccupazioni e portare ad accoppiamento stretto. Per esempio, se si dispone di un oggetto di business che ha i metodi per mutare lo stato, ma è anche decorato al diavolo con le decorazioni EF per il salvataggio in SQL Server e JsonProperty in modo che possa essere inviato su un endpoint API. Questo oggetto potrebbe essere intollerante a cambiare, e sarebbe probabilmente disseminato di varianti di proprietà (ad esempio, UserId, UserPk, UserKey, UserGuid, dove alcuni di loro sono contrassegnati fino a non essere salvato al DB e altri segnato fino a non essere serializzato per JSON a livello di endpoint API).

Quindi, se si dovesse dirmi qualcosa era un DTO, allora probabilmente sarei assicurarsi che fosse mai usato per qualcosa di diverso lo spostamento dello stato in giro. Se mi ha detto qualcosa è stato un modello di vista, allora probabilmente sarei assicurarsi che non si stava salvato in un database. Se mi ha detto che c'era qualcosa che un modello di dominio, allora probabilmente sarei assicuro che had dipendenze su qualsiasi cosa al di fuori del dominio. Ma se mi hai detto che c'era qualcosa che a Poco, non sarebbe davvero dirmi molto a tutti.

Answer 10

Non fanno così anche chiamarli DTOs. Si chiamano Modelli .... Periodo. I modelli non hanno un comportamento. Non so che si avvicinò con questo DTO muto termine, ma deve essere una cosa NET è tutto quello che posso capire. Pensate di vista modelli in MVC, stessa diga ** cosa, i modelli vengono utilizzati per trasferire lo stato tra lato server o strati nel corso del periodo di filo, sono tutti i modelli. Proprietà con i dati. Si tratta di modelli che si passa ove il filo. Modelli, Modelli Modelli. Questo è tutto.

Vorrei che la stupida termine DTO sarebbe andato via dal nostro vocabolario.