C# D a constructor e inyección de dependencia

Question

Me gustaría saber cuál es la mejor práctica en el diseño de constructores de objetos DTO.

decir que tengo un objeto Dto así:

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

Hay varias maneras de construir el objeto:

pude declarar un constructor:

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

Cuando vea este constructor y de inmediato concluir una violación de SRP (responsabilidad única)?

Aunque estos atributos están todos relacionados.

También podría argumentarse que no es necesario validar las propiedades, ya que es una DTO y no tiene ningún comportamiento, y el comportamiento debería estar más bien en el objeto de dominio del que se asigna.

En C# también puede construir más elegante este objeto:

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

O utilizar un constructor de fluidez o un marco como NBuilder.

También está el uso de marcos de mapeo automático como Automapper. El problema también es usar un contenedor Ioc, el código se vuelve complejo, así como el riesgo de intercambiar argumentos, por ejemplo, se pasa el nombre donde está el apellido o viceversa, la validación podría pasar por alto esta asignación más fácil que explícita como se indicó anteriormente.

Por favor ayuda a convencerme de cuál es la mejor manera.

Answer 1

Los tipos de valores como en los ejemplos no son dependencias. Una dependencia proporciona una funcionalidad (o configuración) para el consumidor. En su caso, son solo valores normales que están asignados a su DTO. Siempre que los datos estén juntos, no violará el SRP incluso si asigna muchos valores en el constructor. La única responsabilidad en este caso es retener los datos.

Además, los DTO no deben crearse con un contenedor IoC y no tienen dependencias reales. Debe crearlos manualmente, mediante su marco de persistencia o mediante la asignación automática.

Si la asignación de los valores usando un constructor o propiedades es mejor depende del uso. Si se requieren, la variante del constructor es mejor. Si son opcionales, la propiedad es mejor.

Answer 2

Sugeriría el uso de estructuras de datos inmutables para que la entidad DTO no exponga a ningún setter, obviamente de esta manera el constructor debería proporcionar la capacidad de inicializar todas las propiedades subyacentes de un DTO dado.

así que prefiero:

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

DTO es un objeto de transferencia de datos, especialmente para representar un conjunto de propiedades que pasar a través de un sistema (distribuido también) las fronteras, por lo que no molesta demasiado con respecto SRP violación. Esto es como el patrón de diseño de Fachada, que incluye un conjunto de operaciones/servicios para simplificar el uso. Entonces en este kase Keep It Simple ganó.