Architetto nella nostra azienda è contro DTO [chiuso]

Question

Architetto nella nostra azienda è contro DTO [chiuso]

#1 da (7 voti)
#2 da (4 voti)
#3 da (3 voti)
#4 da (1 voti)
#5 da (0 voti)

2

Ho questo facile DTO (Data Transfer Object) :

public class SoonestOffersModel
{
    public Offer Offer { get; set; }
    public DateTime Date { get; set; }
}

L'offerta è un'entità. Il nostro architetto è contrario a questi DTO, perché sta dicendo che è molto vecchio ed è necessario solo quando le persone non pensano al design per includere tutti i campi prima.

È contrario al primo approccio al modello o al database e preferisce l'approccio al codice prima. In questo caso ha modelli di entità pre-creati.

Quindi gli ho chiesto se volevamo fare qualche logica aggiuntiva e applicare Data con l'entità Offer per View, ha suggerito che avrei dovuto aggiungere il campo DateTime nullable nel modello di entità Offer stesso.

La prima volta che sento questo. Quindi se hai nuove richieste ogni volta che mostri sempre più campi che corrispondono a Offerta, stai aggiungendo quelli nel modello di entità?

Non sono sicuro del perché DTO sia cattivo, dal momento che l'ho sempre usato e non faccio il primo approccio al codice.

Mi piacerebbe sentire la tua opinione su quanto è vero e se dovrei preoccuparmi di questo?

c# asp.net-mvc

posta Amel Salibasic 30.11.2015 - 11:57

fonte

5 risposte

Leggi altre domande sui tag c# asp.net-mvc

Word per specificare che un albero ha numeri arbitrari di rami, al contrario di un albero binario Esiste una programmazione orientata al protocollo?

score 7 · Answer 1

Sembra che il tuo architetto non sia contrario a DTO tanto quanto il tuo architetto si oppone al DTO questo . Sostengono che avere un DTO che è un Offer con un Date attaccato su è un po 'un odore. Non so se la data dovrebbe essere solo parte dell'Offerta o no. In alcuni casi, dovrebbero essere distinti perché il dominio dice che dovrebbero essere cose separate. In altri, dovrebbero stare insieme perché il dominio dice che dovrebbero essere coesi.

Sebbene le DTO siano lì solo per creare bundle di dati stupidi e ben definiti che fungono da contratto agonistico per l'implementazione di alcuni codici esterni. A volte questa è un'API esterna, a volte è il tuo archivio dati, a volte è solo un altro modulo. Quel concetto è buono e buono, ma è solo uno strumento. I buoni strumenti possono ancora essere utilizzati in modo improprio.

score 4 · Answer 2

"Code First" è il lavoro del diavolo. I dati sono ciò che è importante, il codice è solo un processo temporaneo che va e viene, che viene refactored e persino totalmente riscritto in tempo ma i tuoi dati sono sacrosanti. Quindi ottenere gli schemi correttamente è molto più importante a lungo termine.

Detto questo, una mappatura semplicistica di entità a DTO come te è pigra e probabilmente inefficiente. Per ottenere il massimo dal tuo database, dovresti creare metodi che eseguono specifici processi di dominio e creare un oggetto per trasmettere solo i dati richiesti, non tutti i dati restituiti dalla tabella o dalla vista. Idealmente dovresti chiamare una procedura memorizzata che ha restituito un set minimo di dati per l'attività specifica.

score 3 · Answer 3

Il tuo DTO in questo caso non è altro che l'oggetto Offerta più un campo. Sarei d'accordo con l'architetto in questo caso, si dovrebbe semplicemente aggiungere la data all'oggetto di offerta anziché creare un nuovo oggetto.

In genere i DTO sono più piccoli degli oggetti con dominio avanzato nel modello. Ad esempio, l'oggetto offerta potrebbe contenere 50 proprietà, ma l'invio di quei dati (tutti i 50) attraverso il filo potrebbe non essere necessario. Quindi creiamo un DTO con solo le proprietà [N] necessarie per il trasferimento. Forse sono solo 10 o 20 proprietà che devono passare attraverso il filo invece del modello in piena regola.

Potresti non aver bisogno di DTO. Se l'oggetto che attraversa il filo è uguale a quello nel modello, perché creare un altro oggetto? In questo caso l'oggetto DTO È l'oggetto nel modello di dominio + un campo. Niente di male, basta fare attenzione ad avere un approccio coerente su quando e dove usare un DTO.

Dati e strutture dati sono importanti. Un modello e una struttura mal progettati possono rendere il sistema duro e da incubo piuttosto che facile da estendere e comprendere.

score 1 · Answer 4

Tendo ad essere diffidente nei confronti di DTO. Uno degli obiettivi del design orientato agli oggetti consiste nel raggruppare insieme dati e logica (in una classe). Un DTO, per definizione, è puro dato, senza logica.

Nel tuo caso specifico, sembra che la data e l'offerta abbiano una strong coesione. Se vuoi mantenere le specificità di un'offerta con data e un'offerta senza data, potresti voler utilizzare l'ereditarietà:

public class SoonestOffersModel : Offer
{
    public DateTime Date { get; set; }
}

Questo potrebbe essere un buon momento per rileggere GRASP che ti fornirà alcuni suggerimenti su come scegliere dove mettere ogni responsabilità ...

score 0 · Answer 5

L'approccio "Code First" è fantastico. Il database è solo una memoria di persistenza per i dati gestiti dal nostro codice. Dovrebbe essere sacrificabile. Non dovremmo aver bisogno di preoccuparsene. Dovremmo essere in grado di abbandonare il database e rieseguire il nostro codice e farlo ricreare il database da zero.

Alla luce di ciò, non abbiamo bisogno di DTO. Il nostro modello di classe è tutto ciò che è necessario e sufficiente per descrivere in modo completo come dovrebbe essere lo schema del database. Le DTO sono solo uno strato non necessario, che non ha altro scopo se non quello di rendere le cose familiari a chi ha una visione più tradizionale delle cose.

Dovremmo concentrarci sulla scrittura del codice per risolvere il problema in questione, non dovremmo sprecare il nostro tempo a curare l'archiviazione della persistenza.

Modifica

Ovviamente, tutto quanto sopra dipende dal tipo di ambiente in cui si sta lavorando. Se si memorizzano grandi quantità di dati che vengono utilizzati da varie applicazioni, quindi nel proprio ambiente "i dati sono re", quindi " prima il codice "potrebbe non essere adatto a te. Ma suppongo che l'architetto della tua azienda conosca meglio il tipo di ambiente che hai lì.