Dominio vs DTO vs ViewModel - Come e quando usarli?

In un progetto multilivello con livello di dominio (DL)/Business (servizio) Layer (BL)/Presentation Layer (PL), qual è l'approccio migliore per fornire entità al livello di presentazione?Dominio vs DTO vs ViewModel - Come e quando usarli?

DO => Domain Object; 
DTO = Domain Transfer Object; 
VM => View Model; 
V => View;

Opzione 1:

DL => DO => BL => DTO => PL => VM => V

Questa opzione sembra essere la migliore pratica, ma sembra anche pesante da mantenere.

Opzione 2:

DL => DO => BL => DTO => PL => V

Questa opzione non sembra molto buona pratica, ma come DTO sono quasi identiche al VM, si può passare direttamente alla vista ed è meno doloroso da implementare e mantenere.

Questa opzione è anche affidabile per più layout, ad esempio per dispositivi mobili Potrei aver bisogno di meno informazioni dal BL, quindi mi occorrerà una diversa VM per questo particolare layout?

fonte

2012-10-13 Patrick

Se si hanno visioni diverse che richiedono dati diversi dalla propria Dto, sembra che si possa trarre vantaggio dall'avere modelli di visualizzazione diversi per questi e mappare il Dto a questi.

Una delle idee alla base di questo è consentire una maggiore libertà di cambiare il modello di visualizzazione, sapendo che non avrà alcun impatto su qualsiasi altra parte della vostra applicazione. Se la tua Dto viene utilizzata in più viste, ogni modifica al tuo Dto richiederebbe di testare ciascuna vista.

fonte

2012-10-13 15:10:47 dove

Grazie per la risposta, quindi stai dicendo che ogni Dto dovrebbe avere la propria VM in un punto di vista della manutenzione? – Patrick

È possibile utilizzare la Dto direttamente in alcune viste di amministrazione o quando viene utilizzata solo in un unico punto. Creazione dei modelli di viste una volta che si vede la necessità di usare dto in più di una posizione. D'altra parte, se si sta andando con il dominio, l'approccio di Dto, Viewmodel non ci vuole molto tempo per creare gli oggetti extra (con automapper tra) e risparmia in qualsiasi momento cercando di decidere quale usare. Rende più chiaro per chiunque altro sul progetto sapere cosa fare. IMHO, questo potrebbe risparmiare più tempo a lungo termine e rendere il tuo codice un po 'mantenibile. Avere solo viewmodels in viste aiuta in diversi modi ... – dove

come sempre, dipende dal tuo dominio, squadra e dimensione del progetto. – dove

È OK passare il DTO alla vista. Se è necessario modificare o migliorare il DTO, creare un ViewModel. Uno scenario comune sarebbe quello di aggiungere collegamenti. Va anche bene che ViewModel faccia riferimento al DTO come una proprietà complessa.

fonte

2012-10-13 15:10:58

Grazie per la tua risposta, ma non sarebbe meglio usare sempre la stessa architettura piuttosto che usare in alcune situazioni l'opzione 1 e in altri l'opzione 2? – Patrick

Direi di usare la tecnica giusta per completare l'operazione a portata di mano.Non suggerirei di creare un modello di visualizzazione per creare un modello di vista. –

@Patrick per coerenza sì. Ecco perché ho detto "OK" e non "meglio" pratica. "La mia scelta è creare sempre ViewModel e fare riferimento al DTO come una proprietà complessa. –

Vedi qui la mia risposta: https://stackoverflow.com/a/14059156/1288063

Tu dici: Questa opzione sembra essere la migliore pratica, ma sembra anche pesante da mantenere.

pesante da implementare forse, basta poche righe di codice per duplicare la maggior parte del tempo, ma per mantenere sicuramente no.

fonte

2012-12-27 18:24:07

Questa decisione si basa su dove ho inserito la mia logica di convalida.

Scenario n. 1: l'aggiunta di un'annotazione dati in viewmodel (nel livello dell'interfaccia utente) semplifica enormemente la programmazione. Per lo più ci sarà una mappatura uno a uno tra DTO e modello di vista. In questi casi l'opzione 1 è buona. DL => DO => BL => DTO => PL => VM => V

Scenario n. 2) Se la convalida non è collegata a ViewModels, DTO viene sostituito con ViewModel e ViewModel risiede nel livello aziendale. DL => DO => BL => VM => PL => V

Lo scenario n. 2 può essere perfetto in situazioni in cui la logica di convalida risiede nei modelli di dominio. E questi modelli sono usati da molte applicazioni UI. L'interfaccia utente elenca solo gli errori in un elenco, come indicato dal livello aziendale (non molto intuitivo). Poiché l'applicazione subisce modifiche alle regole aziendali, modifichiamo solo il modello di dominio. Anche in questo caso, le convalide relative al database possono essere generate automaticamente tramite EF (se si utilizza .net), ancora meno possibilità di cambiamento.

fonte

2013-12-05 21:32:42

Dominio vs DTO vs ViewModel - Come e quando usarli?

risposta

Problemi correlati