Форма 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, которая не соответствует тому, что вы связываете для достижения.