Несколько вопросов о DTO
Прочёл несколько статей о DTO. В целом, концепция ясна, уже начал её использовать, но осталось несколько непонятных моментов.
- Допустимо ли устанавливать значения по умолчанию для полей в классах DTO? Например для условного UserDTO:
public class UserDTO
{
public string FirstName { get; set; } = "John";
public string LastName { get; set; } = "Galt";
public bool IsMarried { get; set; } = false;
public int NumberOfChildren { get; set; } = 0;
public string Citizenship { get; set; } = "U.S.";
...
}
Обычно пишут, что в DTO не должно быть логики, только свойства. Но ведь свойства и нужны для придания дополнительной логики обычным переменным! То есть в геттеры и сеттеры всё же можно добавлять логику?
Что насчёт конструкторов? Их наличие допустимо?
Одно из применений для DTO я вижу в упрощении создания объектов. То есть вместо длинных конструкторов с десятком параметров
public User(string firstName = "John", string lastName = "Galt", bool isMarried = false, int numberOfChildren = 0, string Citizenship = "U.S."...принимать и обрабатывать DTO
public User(UserDTO user)Правильное ли это использование?
Ответы (1 шт):
- Допустимо, однако тут есть тонкая грань. К примеру для какого-нибудь dto который потом заммапится для создания сущности (dto -> entity) не надо указывать значения по умолчанию, лучше в методе после маппинга задать значения по умолчанию свойствам сущности (очень хорошо подходит для этого
Fluent Builder). Например:
public class PagedAndSortedRequestDto
{
public int MaxResultCount { get; set; } = 10;
public int SkipCount { get; set; }
public string Sorting { get; set; }
}
Тут вполне нормально установить дефолтное значение для MaxResultCount, но недопустимо для SkipCount и Sorting.
- В DTO не должно быть никакой логики. DTO это просто класс-обёртка для передачи данных
- Да, допустимо, но делайте конструктор по-умолчанию (если объект подразумевает создание его каким-нибудь AutoMapper)
- DTO не предназначено для доменных сущностей, это абсолютно разные слои