Forma DTO: plana, compleja/anidada, o una mezcla de ambos

Question

Tengo una aplicación MVC2 n-tier (DAL, Dominio, Servicio, MVC web) usando un enfoque DDD (Diseño Dirigido por Dominio), teniendo un Modelo de Dominio con repositorios. Mi capa de servicio usa un patrón Solicitud/Respuesta, en el que los objetos Solicitud y Respuesta contienen DTO (Objetos de transferencia de datos) para ordenar los datos de una capa a la siguiente, y la asignación se realiza a través de la ayuda de AutoMapper. Mi pregunta es la siguiente: ¿qué forma debería tomar una DTO? ¿Puede tener anidado/complejo DTO también o debería ser estrictamente una proyección plana? ¿O posiblemente una mezcla de ambos? Además, ¿cuáles son las principales razones para tener un DTO plano frente a un DTO más complejo/anidado?

Por ejemplo, supongamos que tenía un dominio como el siguiente:

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

Hay tres maneras diferentes que he pensado de modelar el objeto Response.

Opción 1 - la opción DRYest:

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

De la investigación que he hecho, no sería apropiado para un DTO para tomar una forma similar a la del objeto de dominio (s) como se ha demostrado anteriormente .

Opción 2 - una proyección aplanada del dominio (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; } 
} 

Esto es más simple, como un DTO aparentemente debería ser, pero en última instancia hace que para más DTO.

Opción 3 - una mezcla de ambos:

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

Esto permite que el código sea un poco más seco, reutilizable y manejable, y no expone la estructura de mi dominio para el usuario final . El otro beneficio principal es que otras respuestas, como GetCompanyResponse podrían simplemente devolver CompanyDTO, sin tener que hacer una copia de todas esas propiedades, similar a la opción 2. ¿Qué opina usted? ¿Qué opción de estos (si corresponde) ha tomado y/o ha trabajado para usted? Si estas Solicitudes/Respuestas se exponen posteriormente como métodos de servicio de WCF, ¿cambia su respuesta?

Answer 1

Mi preferencia personal sería tratar de mantenerlo plano como sea posible con solo transferir los datos requeridos. una vez dicho esto, he utilizado DTO profundamente anidado en el pasado porque tenía sentido en ese momento y se ajustaba a los requisitos. así que supongo que todo se reduce a "depende". Al final del día, vaya con lo que tenga sentido para la aplicación en cuestión. No tiene sentido tratar de meter los datos de cuerno en una convención de DTO que no se ajusta a lo que está tratando de lograr.