POCO vs DTO: va bene idratare parzialmente un oggetto di dominio?

Question

Spesso è necessario avere un oggetto dominio visualizzato in vari modi sull'interfaccia utente; elenchi, risultati di ricerca, visualizzazione e modifica di pagine, nonché in intestazioni, piè di pagina e popup. In genere hai diverse "viste" diverse dell'oggetto dominio, ognuno con campi diversi visualizzati.

La maggior parte dei consigli sembra essere quella di utilizzare un DTO per ottenere i dati quando si richiede un sottoinsieme o superset. Ci sono molte spese generali nel mantenimento dei DTO. È un cattivo approccio riempire semplicemente le proprietà dell'oggetto dominio richiesto per ogni scenario. Ad esempio, potresti utilizzare un profilo per dire quali proprietà devono essere incluse, ad esempio:

service.GetDomainObjects (int listID, Profile.ListProfile); service.GetDomainObjects (stringa searchParam, Profile.SearchProfile);

Answer 1

Per me ciò a cui si riduce è dove vuoi che sia l'overhead, o avrai una serie di classi diverse per rappresentare i tuoi DTO, o avrai una serie di metodi che ognuno restituisce lo stesso oggetto di dominio ma con diversi campi che vengono "idratati".

Un paio di domande che vorrei porre per prendere una decisione sono:

• qual è il sovraccarico nell'idratazione dell'intero oggetto? La complessità aggiunta (di DTO o oggetti parzialmente idratati) è davvero utile?
• qualcun altro utilizzerà il tuo codice? Non confondere le persone con oggetti idratati per via paritaria, i DTO potrebbero essere più chiari quando le persone vengono a mantenere il tuo codice.

Ho una leggera preferenza personale per i DTO poiché ritengo che la manutenzione a lungo termine del sistema sarà più semplice. Se sei un one man band, o questa è un'app da buttare via, posso capire perfettamente che non voglio introdurre un mucchio di classi extra che ingombreranno il tuo codice.