C # Dto конструктор и внедрение зависимостей

Question

Я хотел бы знать, что является наилучшей практикой при проектировании конструкторов объектов DTO.

говорят, что у меня есть объект Dto, подобный этому:

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

Есть несколько способовсоздать объект:

Я мог бы объявить конструктор:

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

Когда вы видите этот конструктор и сразу заключаете нарушение SRP (Single ответственность)?

Даже если этивсе атрибуты связаны между собой.

Можно также утверждать, что нет необходимости проверять свойства, так как это DTO и поведение НЕТ, и поведение должно быть скорее для объекта домена, с которым это сопоставляется.

В C # мы также можем более элегантно построить этот объект:

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

Или использовать свободный конструктор или фреймворк, такой как NBuilder.

Существует также использование Auto mappingрамки, такие как Automapper.Проблема также заключается в использовании контейнера Ioc, в котором ctor становится сложным, а также в связи с риском подмены аргументов, например, если вы передаете имя, где фамилия, или наоборот, проверка может пропустить это более простое, чем явное отображение, как указано выше.

Пожалуйста, помогите убедить меня, какой путь лучше.

Answer 1

Типы значений, как в ваших примерах, не являются зависимостями. Зависимость предоставляет функциональность (или конфигурацию) потребителю. В вашем случае это просто нормальные значения, которые присваиваются вашему DTO. Пока данные принадлежат друг другу, вы не нарушаете SRP, даже если вы назначаете много значений в конструкторе. В этом случае единственной обязанностью является хранение данных.

Также DTO не должны создаваться контейнером IoC и не иметь реальных зависимостей. Вы должны создать их вручную, с помощью вашей инфраструктуры постоянства или с помощью автоматического сопоставления.

Если присвоение значений с помощью конструктора или свойств лучше, зависит от использования. Если они требуются, вариант конструктора лучше. Если они не являются обязательными, лучше использовать свойство.

Answer 2

Я бы предложил использовать неизменяемые структуры данных, чтобы сущность DTO не выставляла никаких сеттеров, очевидно, таким образом конструктор должен обеспечивать возможность инициализации всех базовых свойств данного DTO.

Поэтому я предпочитаю:

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

DTO - это объект передачи данных, особенно для представления набора свойств, которые должны быть переданы через границы системы (в том числе и распределенные), поэтому не стоит слишком беспокоиться о нарушении SRP .Это похоже на шаблон проектирования Фасад, он абстрагирует набор операций / услуг для упрощения использования.Так что в этой казе Keep It Simple выиграл.