Spring MVC: il livello di servizio deve restituire DTO specifici di operazioni?

Question

Nella mia applicazione Spring MVC sto usando DTO nel livello di presentazione al fine di incapsulare il modello di dominio nel livello di servizio. I DTO vengono utilizzati come oggetti di sostegno della forma della molla.

quindi i miei servizi simile a questa:

userService.storeUser(NewUserRequestDTO req); 

Il livello di servizio si tradurrà DTO -> oggetto Dominio e fare il resto del lavoro.

Ora il mio problema è che quando voglio recuperare un DTO dal servizio per eseguire un aggiornamento o una visualizzazione, non riesco a trovare un modo migliore di farlo per avere più metodi per la ricerca che restituiscono diversi DTO è come ...

EditUserRequestDTO userService.loadUserForEdit(int id); 

DisplayUserDTO userService.loadUserForDisplay(int id); 

ma qualcosa non sembra giusto per questo approccio. Forse il servizio non deve restituire cose come EditUserRequestDTO e il controllore deve essere responsabile di assemblare un requestDTO da un formulario oggetto dedicato e viceversa.

Il motivo hanno separato DTO è che DisplayUserDTO è fortemente tipizzato per essere letto solo ed inoltre ci sono molte proprietà di utenti che sono entità di una tabella di ricerca nel db (come città e stato) in modo che il DisplayUserDTO avrebbe il descrizione delle stringhe delle proprietà mentre EditUserRequestDTO avrà gli id ​​che sosterranno gli elenchi a discesa di selezione nei moduli.

Cosa ne pensi?

grazie

Answer 1

mi piacciono gli oggetti di visualizzazione smontati. È più efficiente della creazione dell'intero oggetto dominio solo per visualizzarne alcuni campi. Ho usato un modello simile con una differenza. Invece di usare una versione di modifica di un DTO, ho semplicemente usato l'oggetto dominio nella vista. Ha ridotto significativamente il lavoro di copia dei dati avanti e indietro tra gli oggetti. Non ho ancora deciso se voglio farlo ora, dal momento che sto utilizzando le annotazioni per APP e il quadro Bean Validation e mescolando le annotazioni sembra disordinato. Ma non mi piace usare DTO al solo fine di mantenere gli oggetti di dominio fuori dal livello MVC. Sembra un sacco di lavoro per non molto beneficio. Inoltre, potrebbe essere utile leggere Fowler's take su anemic objects. Potrebbe non essere applicabile esattamente, ma vale la pena pensarci.

---

1 ° Edit: rispondere al seguito commento.

Sì, mi piace usare gli oggetti di dominio effettivo per tutte le pagine che operano su un singolo oggetto per volta: Modifica, Visualizza, creare, ecc

Hai detto che sta assumendo un oggetto e la copia esistente i campi necessari in un DTO e quindi il passaggio del DTO come parte del modello al motore dei modelli per una pagina di visualizzazione (o viceversa per una creazione). Cosa ti compra? Il riferimento al DTO non ha un peso inferiore rispetto al ref dell'oggetto dominio completo, e hai a disposizione tutti gli attributi aggiuntivi per copiare. Non c'è una regola che dice che il tuo motore di template deve usare ogni metodo sul tuo oggetto.

userei un piccolo oggetto di dominio parziale se si migliora l'efficienza (senza grafici di relazione per costruire), soprattutto per i risultati di una ricerca. Ma se l'oggetto esiste già, non preoccuparti di quanto sia grande o complesso quando lo si attacca nel modello per rendere una pagina. Non sposta l'oggetto in memoria. Non causa lo stress del motore dei modelli. Accede solo ai metodi di cui ha bisogno e ignora il resto.

---

2a modifica: Buon punto. Ci sono situazioni in cui vorresti un insieme limitato di proprietà disponibili per la vista (ad esempio diversi sviluppatori front-end e back-end). Dovrei leggere più attentamente prima di rispondere. Se avessi intenzione di fare ciò che vuoi, probabilmente metterei metodi separati su User (o qualsiasi altra classe) del modulo per Edit() e forDisplay(). In questo modo puoi semplicemente ottenere Utente dal livello di servizio e dire all'Utente di darti l'uso di copie limitate di se stesso. Penso che forse è quello che stavo cercando con il commento degli oggetti anemici.

Answer 2

È necessario utilizzare un DTO e mai un ORM nel livello MVC! Esistono molte domande davvero buone su questo argomento, come ad esempio: Why should I isolate my domain entities from my presentation layer?

Ma per aggiungere a questa domanda, è necessario separarle per evitare che l'ORM venga associato a un messaggio poichè esiste il potenziale per qualcuno di aggiungere un campo in più e causare tutti i tipi di caos che richiedono inutili validazioni extra.