Форма DTO: плоская, сложная / вложенная или смесь обоих
у меня есть приложение mvc2 n-уровня (DAL, Domain, Service, MVC web), использующее подход DDD (Domain Driven Design), имеющий модель домена с репозиториями. Мой уровень обслуживания использует запрос/ответ, в котором объекты запроса и ответа содержат объекты DTO (объекты передачи данных) для маршалирования данных с одного слоя на другой, а сопоставление выполняется с помощью AutoMapper. Мой вопрос таков:--9-->какую форму обычно должен принимать DTO? может ли он иметь вложенные/комплекс DTO также или должно быть строго квартира проекция? или, возможно, смесь обоих? кроме того, каковы основные причины наличия плоского DTO против более сложного/вложенного DTO?
например, предположим, что у меня есть домен, такой как:
public class Employee
{
public string FirstName { get; set; }
public string LastName { get; set; }
public Company Company { get; set; }
}
public class Company
{
public string Name { get; set; }
public string Address { get; set; }
public string City { get; set; }
public string State { get; set; }
}
есть три разных способа моделирования объекта ответа.
1 - в DRYest вариант:
public class GetEmployeeResponse
{
public class EmployeeDTO { get; set; } // contains a CompanyDTO property
}
из исследования, которое я сделал, было бы неуместно для DTO принимать аналогичную форму, как объект(ы) домена, как показано выше.
2 - уплощенная проекция домена (анти-сухой):
public class GetEmployeeResponse
{
public string FirstName { get; set; }
public string LastName { get; set; }
public string CompanyName { get; set; }
public string CompanyAddress { get; set; }
public string CompanyCity { get; set; }
public string CompanyState { get; set; }
}
это более просто, как DTO, по-видимому, должно быть, но в конечном итоге делает больше DTO.
3 - смесь обоих:
public class GetEmployeeResponse
{
public EmployeeDTO Employee { get; set; }
public CompanyDTO Company { get; set; }
}
это позволяет код должен быть немного более сухим, многоразовым и управляемым и не подвергать мою доменную структуру конечному пользователю. Другим основным преимуществом является то, что другие ответы, такие как GetCompanyResponse
может просто вернуть CompanyDTO
, без необходимости делать копию всех этих свойств, аналогично варианту 2. А ты как думаешь? Какой из этих вариантов (если таковые имеются) вы приняли и/или работали на вас? Если эти запросы/ответы позже будут представлены как методы службы WCF, изменится ли ваш ответ?
1 ответов
моим личным предпочтением было бы попытаться сохранить его как можно более плоским, передавая только необходимые данные. сказав, что я использовал глубоко вложенный DTO в прошлом, потому что это имело смысл в то время и соответствовало требованиям. поэтому я думаю, что это сводится к"это зависит". В конце дня пойти с тем, что имеет смысл для приложения под рукой. Нет смысла пытаться обувать данные Рога в Конвенцию DTO, которая не соответствует тому, что вы связываете для достижения.