Forme DTO: plate, complexe/imbriquée, ou un mélange des deux

Question

J'ai une application MVC2 n-tier (DAL, domaine, service, web MVC) en utilisant une approche DDD (Domain Driven Design), ayant un modèle de domaine avec référentiels. Ma couche de service utilise un modèle de requête/réponse , dans lequel les objets Request et Response contiennent des objets DTO (Data Transfer Objects) pour rassembler les données d'une couche à la suivante et le mappage est effectué via l'aide d'AutoMapper. Ma question est la suivante: quelle forme devrait normalement prendre un DTO? Peut-il avoir imbriqué/complexe DTO aussi bien ou devrait-il être strictement une plate projection? Ou peut-être un mélange des deux? En outre, quelles sont les principales raisons d'avoir un DTO plat par rapport à un DTO plus complexe/imbriqué?

Par exemple, supposons que j'avais un domaine tel que:

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; } 
} 

Il existe trois façons différentes que j'ai pensé de modéliser l'objet Response.

Option 1 - l'option plus sec:

public class GetEmployeeResponse 
{ 
    public class EmployeeDTO { get; set; } // contains a CompanyDTO property 
} 

De la recherche que je l'ai fait, il serait inapproprié pour un DTO de prendre une forme similaire à l'objet de domaine (s) comme démontré ci-dessus .

Option 2 - une projection aplatie du domaine (anti-DRY):

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; } 
} 

Ceci est plus simple, comme un DTO devrait apparemment être, mais en fin de compte fait pour plus DTO.

Option 3 - un mélange des deux:

public class GetEmployeeResponse 
{ 
    public EmployeeDTO Employee { get; set; } 
    public CompanyDTO Company { get; set; } 
} 

Cela permet le code d'être un peu plus sec, réutilisable et facile à gérer, et ne pas exposer ma structure de domaine à l'utilisateur final . L'autre avantage principal est que d'autres réponses, comme GetCompanyResponse pourraient simplement retourner CompanyDTO, sans avoir à faire une copie de toutes ces propriétés, semblable à l'option 2. Que pensez-vous? Quelle option avez-vous prise et/ou avez-vous utilisée pour vous? Si ces demandes/réponses sont exposées ultérieurement en tant que méthodes de service WCF, votre réponse change-t-elle?

Answer 1

Ma préférence personnelle serait d'essayer de rester aussi plat que possible avec seulement les données requises étant transférées. Après avoir dit que j'ai utilisé le DTO profondément imbriqué dans le passé parce que cela avait du sens à l'époque et correspondait aux exigences. donc je suppose que cela se résume à "ça dépend". À la fin de la journée, allez avec ce qui est logique pour l'application à portée de main. Il est inutile d'essayer de faire passer les données du klaxon dans une convention DTO qui ne correspond pas à ce que vous cherchez à obtenir.