Qual è il modo migliore per creare DTO da entità e aggiornare entità da DTO in un'architettura a più livelli?

2

Opzione 1:

In un primo momento avrei effettuato una chiamata al mio livello di servizio, che serviva da API per il mio dominio principale, per ottenere un oggetto dominio o un elenco di oggetti dominio e quindi passarli nell'assembler che costruiva i DTO di cui avevo bisogno per la mia vista Il problema che ho con questo approccio sono i casi in cui l'oggetto dominio è grande e non voglio caricare l'intero oggetto solo per copiare alcuni campi necessari per il DTO (cioè mostrare un elenco di entità dei sommari).

Opzione 2:

Il prossimo approccio che ho usato è stato quello di collegare un repository (per scopi di sola lettura) al mio assemblatore in modo da poter interrogare il database solo per i campi che mi servono nel DTO. Posso anche usare questo repository quando ottengo un DTO e devo usarlo per aggiornare ed entità. Ad esempio, un DTO riempito valuterà i valori che ho bisogno di aggiornare sulla mia entità entra nel mio assemblatore, l'assemblatore cerca l'entità da un repository e quindi sovrappone le informazioni dal DTO all'entità e quindi restituisce l'entità. Il controller chiama quindi il livello di servizio per salvare l'entità restituita dall'assemblatore.

Opzione 3:

Potrei collegare i repository direttamente ai controller ma qualcosa sull'esposizione del repository nel controller mi sembra sbagliato perché il livello del servizio dovrebbe gestire le transazioni e la sicurezza, ma poi di nuovo, se metto un repository nell'assemblatore I sto fondamentalmente facendo la stessa cosa.

Ogni pensiero è benvenuto. Voglio solo capire i pro ei contro e ciò che ha funzionato bene per gli altri.

    
posta testing123 31.03.2015 - 07:24
fonte

2 risposte

1

Ok. Problema 1: acquisizione di DTO dalle entità:

Poiché le tue entità possono esporre pubblicamente i loro dati, puoi accedere alle loro proprietà e installare un oggetto DTO o semplicemente serializzare direttamente l'entità

Problema 2: entità da DTO:

Un metodo di costruzione che prende un elenco delle proprietà da impostare può essere chiamato usando le proprietà del DTO

Problema 3: entità grandi quando hai solo bisogno di informazioni di riepilogo

Crea un nuovo oggetto di riepilogo che puoi recuperare dal repository. Nota Ti suggerisco di creare repository strongmente tipizzati con metodi come Repo.GetMyObjectById (id stringa) piuttosto che esporre un ORM generico.

Problema 4: dove eseguire l'orcestrazione di tutto questo.

La mia raccomandazione è di avere una classe di servizio di un livello inferiore al tuo servizio / app / sito web di hosting.

Questo ha accesso ai repository DTO e le entità ei suoi metodi si associano ai controller / chiamate di servizio della tua applicazione in modo che tu non abbia bisogno di alcun codice al livello più alto e possa ospitare lo stesso servizio in modi mutipli.

Fornire l'accesso ai repository non è un problema quando puoi utilizzarli solo per ritirare le entità invece di fare qualsiasi query a loro piaccia.

Mettere questa logica assembly / orcestration all'interno dell'entità è solitamente scorretto in quanto si vorrà riutilizzare l'entità per altri scopi.

Questo servizio di primo livello dovrebbe essere molto leggero. Semplicemente, prendi questi oggetti, chiama questo metodo, crea e restituisci il risultato / DTO / viewmodel

Perché è così leggero che non è un problema enorme se salti il livello e inserisci il codice nel tuo controller. Ma ti farà risparmiare tempo se cambi il livello di hosting e aiuti con i test etc

    
risposta data 29.06.2015 - 09:22
fonte
-2

Personalmente non userei nessuna di queste opzioni. Eviterei l'uso di repository tutti insieme e uso solo le query ADO.NET e SQL per mappare i dati sul mio DTO direttamente nel livello dell'applicazione. O se preferisci uno strato di facciata di query molto sottile.

Utilizziamo questo metodo con grande successo al momento. Effettuare una query su più modelli di dominio non ti dà alcun vantaggio reale e generalmente ti darà scarse prestazioni. A mio avviso, non c'è una vera ragione per coinvolgere le entità di dominio.

    
risposta data 29.03.2015 - 18:38
fonte