¿Cuál es el sentido de un objeto de transferencia de datos (DTO)?

Question

¿Por qué debería usar DTOs/objetos de Dominio cuando puedo simplemente colocar todas las clases de negocios en una biblioteca de clases, usarlas en la lógica de negocios, y luego pasar esos mismos objetos de negocios a las clases de límites?

ACTUALIZACIÓN: Todos son buenos puntos, gracias por la ayuda. Una pregunta de seguimiento:

¿Dónde coloca típicamente estos DTO? ¿Junto a los objetos de Dominio, es decir, en el mismo espacio de nombres?

namespace MedSched.Medical 
{ 
    public class MedicalGroup 
    { 
     //... 
    } 

    public class MedicalGroupDTO 
    { 
     //... 
    } 
} 

Answer 1

• El DTO de proporcionar una capa de abstracción para su modelo de dominio. Por lo tanto, puede cambiar el modelo y no romper el contrato que tiene para sus clientes de servicio. Esto es similar a una práctica común en el diseño de bases de datos donde las vistas y los procedimientos se convierten en la capa de abstracción para el modelo de datos subyacente.
• Serialización: puede sobreexponer datos y enviar mensajes inflados a través del cable. Esto puede mitigarse mediante el uso de atributos de serialización, pero aún puede tener información adicional.
• Contratos implícitos frente a explícitos: al exponer objetos de dominio, deja que el cliente interprete su uso, ya que no tiene el modelo completo a su disposición. A menudo hará actualizaciones a los objetos de dominio implícitamente en función de la presencia o eliminación de asociaciones, o aceptará ciegamente todos los cambios. Los DTO expresan explícitamente el uso del servicio y la operación deseada.
• escenarios desconectados - que tienen mensajes explícitos o dtos harían más fácil para que usted pueda implementar patrones de mensajería y mensajería como Message Broker, etc.
• DDD - DDD pura exige que los objetos de dominio son externamente inmutable, y por lo tanto se deben sacar datos esto a otro objeto, generalmente un DTO.

Answer 2

DTO son Objetos de transferencia de datos, siendo Transfer la palabra clave. Son excelentes cuando desea pasar sus objetos a través del cable y potencialmente comunicarse con un idioma diferente porque son "livianos" (es decir, no tienen lógica comercial)

Si su aplicación no está basada en servicios web, los DTO no están No te voy a comprar nada.

Por lo que la decisión de utilizar o no DTO debe basarse en la arquitectura de su aplicación.

Answer 3

Hay veces cuando el datos que desea pasar no se corresponde exactamente con la estructura de los objetos comerciales, en cuyo caso utiliza DTO.

Ej .: cuando quiere pasar un subconjunto de los datos o una proyección.

Answer 4

puedo pensar en 2 escenarios básicos para utilizar DTO:

• Usted está creando su objeto de negocio a partir de datos que es incompleta y se producirá un error de validación. Por ejemplo, está analizando un archivo CSV o un archivo Excel desde donde se crea su objeto comercial. Si usa datos directamente de estos objetos para crear su objeto comercial, es posible que falle varias reglas de validación dentro del objeto, porque los datos de dichos archivos son propensos a errores. También tienden a tener una estructura diferente que tiene en su objeto comercial final: tener un marcador de posición para esos datos incompletos será útil.

• Está transportando su objeto de negocio a través de un medio con ancho de banda intensivo. Si está utilizando un servicio web, necesitará utilizar DTO para simplificar su objeto antes del transporte; de lo contrario, el CLR tendrá dificultades para tratar de serializar todos sus datos.