Quando è opportuno mappare un DTO alla sua controparte Entità

5

Da quanto ho letto e implementato, DTO è l'oggetto che contiene un sottoinsieme di valori da un modello di dati, nella maggior parte dei casi questi sono oggetti immutabili.

Che dire del caso in cui ho bisogno di passare un nuovo valore o modifiche al database?

Dovrei lavorare direttamente con il modello dati / entità reale dal mio DAL nel mio livello Presentazione?

O dovrei creare un DTO che può essere passato dal livello di presentazione al livello aziendale, quindi convertirlo in un'entità, quindi essere aggiornato nel DB tramite una chiamata ORM. È scritto troppo codice? Suppongo che ciò sia necessario se il livello di presentazione non ha alcun concetto del modello di dati. Se stiamo seguendo questo approccio, dovrei recuperare nuovamente l'oggetto al livello BLL prima di eseguire il cambiamento?

    
posta aggietech 29.12.2014 - 21:46
fonte

2 risposte

4

Se hai un'entità come in un'entità DDD (non ciò che viene generalmente definito un'entità in framework come il framework di entità), allora l'entità dovrebbe proteggere i suoi invarianti. Quindi usare l'entità come DTO è molto probabilmente sbagliato. Un DTO non ha dati di input non convalidati dall'utente e deve essere trattato come tale. Un'entità è costituita da dati convalidati in uno dei tipi di oggetto invarianti validi. Pertanto si dovrebbe avere una conversione tra un DTO e un'entità che converte un DTO convalidato in un oggetto entità dominio.

In molti casi, le persone li ignorano usando modelli di dominio anemici ( link ) dove le "entità" in generale non contengono alcuna logica e quindi inseriscono tutta la logica di protezione invariante ecc. nel codice esterno (e quindi hanno bisogno di controllare invarianti dappertutto). Questo può funzionare, ma secondo me porta a bug. Ma è qualcosa che accade praticamente ovunque - specialmente dal momento che molti framework incoraggiano questo rendendo molto semplice scrivere codice in questo modo. Questo è un po 'troppo male perché porta al modo più semplice / più veloce di codifica che non è quello che porta ai migliori risultati (se segui DDD che è) ...

Ma è anche importante riconoscere che in molti casi DDD potrebbe essere eccessivo. Se stai praticamente facendo un'applicazione CRUD (che in molti casi probabilmente lo sei), DDD potrebbe essere eccessivo per il tuo dominio. Ovviamente questo non significa che dovresti buttare via tutte le buone idee e andare semplicemente in "modalità tutto-nulla", ma in alcuni casi non preoccuparti di certe parti del DDD può essere la scelta giusta da fare. Il difficile trucco qui è, ovviamente, identificare se il tuo dominio è abbastanza complesso da giustificare DDD o se è abbastanza facile non morderti nel culo rinunciare a certe parti di esso. :)

    
risposta data 26.03.2015 - 10:34
fonte
0

Se il tuo livello di presentazione è sempre co-localizzato con il tuo Data Access Layer (DAL), che è spesso il caso di app web server (o GUI standalone) , in genere non è necessario un livello DTO: basta utilizzare direttamente le entità.

Se il tuo livello di presentazione può essere remoto , allora DTO è una buona idea. E, sì, un DTO può essere usato sia in entrata che in uscita, cioè spedisci DTO e ricevi DTO come input per aggiornare il tuo modello persistente attraverso il DAL.

Tuttavia, i quadri moderni hanno in gran parte ovviato a DTO espliciti. Un buon framework MVC del server (es. Spring-MVC / web per Java) consente di lavorare con le classi di entità (dal DAL) direttamente nelle API di primo livello (ad esempio l'interfaccia REST) e fare il marshalling / unmarshalling da / a JSON o XML < em> trasparente . Non fornisci dettagli sufficienti sulla tua applicazione, quindi il tuo chilometraggio potrebbe variare. Se stai utilizzando un meccanismo RPC specifico della lingua (ad es. Java RMI) potresti comunque voler nascondere il tuo modello di entità dal mondo esterno con un livello DTO.

    
risposta data 26.03.2015 - 10:20
fonte

Leggi altre domande sui tag