Форма DTO: плоская, сложная / вложенная или смесь обоих - PullRequest
Новая
       7

Форма DTO: плоская, сложная / вложенная или смесь обоих

20 голосов
/ 12 октября 2010

У меня есть n-уровневое приложение MVC2 (DAL, Domain, Service, MVC web), использующее подход DDD (Domain Driven Design), имеющее модель домена с репозиториями. Мой сервисный уровень использует шаблон запроса / ответа , в котором объекты Request и Response содержат DTO (объекты передачи данных) для перенаправления данных с одного уровня на другой, а сопоставление выполняется с помощью AutoMapper. У меня такой вопрос: какую форму обычно должен принимать DTO? Может ли он иметь также вложенных / сложных DTO или это строго проекция flat ? Или, возможно, смесь обоих? Кроме того, каковы основные причины наличия плоского 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; }
}

Есть три разных способа моделирования объекта Response.

Опция 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 Ответ

11 голосов
/ 12 октября 2010

Мое личное предпочтение будет состоять в том, чтобы попытаться сохранить его как можно более простым, передавая только необходимые данные. сказав, что я использовал глубоко вложенный DTO в прошлом, потому что это имело смысл в то время и соответствовало требованиям. поэтому я думаю, что все сводится к «это зависит». В конце дня рассмотрим, что имеет смысл для приложения под рукой. Нет смысла пытаться включить данные рогов в соглашение DTO, которое не соответствует тому, что вы пытаетесь достичь.

...