valid - remarks c#

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

Question

Tengo una aplicación de nivel MVC2 (DAL, Dominio, Servicio, web de MVC) que utiliza un enfoque DDD (Diseño impulsado por dominio), que tiene un Modelo de dominio con repositorios. Mi capa de servicio usa un patrón de solicitud / respuesta , en el que los objetos de solicitud y respuesta contienen DTO (objetos de transferencia de datos) para calcular 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 tener normalmente un DTO? ¿Puede tener DTOs anidados / complejos también o debería ser estrictamente una proyección plana ? ¿O posiblemente una mezcla de ambos? Además, ¿cuáles son las razones principales para tener un DTO plano frente a un DTO más complejo / anidado?

Por ejemplo, supongamos que tengo 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 formas diferentes en las que he pensado en modelar el objeto Respuesta.

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, sería inapropiado que un DTO tome una forma similar a los objetos de dominio como se demostró 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 serlo, pero en última instancia hace que haya 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 al usuario final. El otro beneficio principal es que otras respuestas, como GetCompanyResponse , simplemente pueden devolver CompanyDTO , sin tener que hacer una copia de todas esas propiedades, similar a la opción 2. ¿Qué piensa? ¿Qué opción de estos (si corresponde) ha tomado y / o ha trabajado para usted? Si estas Solicitudes / Respuestas se exponen más adelante como métodos de servicio WCF, ¿cambia su respuesta?

Answer 1

Mi preferencia personal sería intentar mantenerlo lo más plano posible con solo transferir los datos requeridos. Dicho esto, he usado 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 intentar incluir los datos de la bocina en una convención DTO que no se ajuste a lo que está intentando lograr.