C# Dto constructor e dependency injection

Question

Mi piacerebbe sapere qual è la migliore pratica nella progettazione dei costruttori di oggetti DTO.

dire che ho un oggetto Dto come questo:

class CustomerDto 
{ 
    public string Name { get; set; } 
    public string Surname { get; set; } 
    public string Phone { get; set; } 
    ... 
} 

Ci sono diversi modi per costruire l'oggetto:

ho potuto dichiarare un costruttore:

public CustomerDto(string name, string surname, string phone, ...) 
{ 
    this.Name = name; 
    this.Surname = surname; 
    this.Phone = phone; 
    ... 
} 

Quando si vede questo costruttore e concludere immediatamente una violazione SRP (Responsabilità singola)?

Anche se questi attributi sono tutti correlati.

Si potrebbe anche obiettare v'è alcuna necessità di convalidare le proprietà come questo è un DTO e non ha il comportamento e il comportamento dovrebbe essere piuttosto sull'oggetto dominio che questo le mappe da.

In C# si può anche più elegante costruire questo oggetto:

var dto = new CustomerDto() 
{ 
    Name = "Some name", 
    Surname = "Some surname" 
} 

Oppure utilizzare un costruttore fluente o di un quadro, come NBuilder.

C'è anche l'uso di framework Auto mapping come Automapper. Il problema sta anche usando un contenitore Ioc che il Ctor diventa complesso, così come il rischio nello scambio di argomenti, ad esempio, si passa in nome dove è il cognome o viceversa, la convalida potrebbe perdere questa mappatura più facile quindi esplicita come sopra.

Si prega di aiutare a convincermi che è il modo migliore.

Answer 1

I tipi di valore come nei tuoi esempi non sono dipendenze. Una dipendenza fornisce una funzionalità (o configurazione) al consumatore. Nel tuo caso sono solo valori normali assegnati al tuo DTO. Finché i dati appartengono insieme non si viola SRP anche se si assegnano molti valori nel costruttore. La sola responsabilità in questo caso è quella di conservare i dati.

Anche i DTO non devono essere creati da un contenitore IoC e non hanno reali dipendenze. Dovresti crearli manualmente, dal tuo framework di persistenza o usando la mappatura automatica.

Se l'assegnazione dei valori utilizzando un costruttore o proprietà è migliore dipende dall'utilizzo. Se sono richiesti, la variante del costruttore è migliore. Se sono facoltativi, la proprietà è migliore.

Answer 2

Suggerirei di utilizzare strutture dati immutabili in modo che l'entità DTO non esponga alcun setter, ovviamente in questo modo il costruttore dovrebbe fornire la capacità di inizializzare tutte le proprietà sottostanti di un dato DTO.

quindi preferisco:

public CustomerDto(string name, string surname, string phone, ...) 

DTO è un oggetto di trasferimento dei dati, in particolare per rappresentare un insieme di proprietà per essere passato attraverso un sistema (distribuito pure) confini, quindi non preoccupatevi troppo per quanto riguarda SRP violazione. Questo è come il modello di progettazione della facciata, elimina una serie di operazioni/servizi per semplificare l'utilizzo. Quindi in questo kase Keep It Simple vinto.