¿Por qué los objetos de transferencia de datos (DTO) son un antipatrón?

Recientemente escuché a la gente decir que los objetos de transferencia de datos (DTO) son un antipatrón .

¿Por qué? ¿Cuáles son las alternativas?

Algunos proyectos tienen todos los datos dos veces . Una vez como objetos de dominio y una vez como objetos de transferencia de datos.

Esta duplicación tiene un costo enorme , por lo que la architecture necesita obtener un gran beneficio de esta separación para valer la pena.

Los DTO no son un antipatrón. Cuando está enviando datos a través del cable (por ejemplo, a una página web en una llamada Ajax), quiere asegurarse de que conserve ancho de banda solo enviando datos que usará el destino. Además, a menudo es conveniente que la capa de presentación tenga los datos en un formato ligeramente diferente al de un objeto comercial nativo.

Sé que esta es una pregunta orientada a Java, pero en los lenguajes .NET, los tipos anónimos, la serialización y LINQ permiten que los DTO se construyan sobre la marcha, lo que reduce la configuración y la sobrecarga de su uso.

DTO un AntiPattern en EJB 3.0 dice:

La naturaleza pesada de Entity Beans en las especificaciones EJB anteriores a EJB 3.0, dio como resultado el uso de patrones de diseño como Data Transfer Objects (DTO). Los DTO se convirtieron en los objetos ligeros (que deberían haber sido los beans de entidad en primer lugar), utilizados para enviar los datos a través de los niveles … ahora la especificación EJB 3.0 hace que el modelo de bean Entity sea el mismo que el antiguo objeto Java simple (POJO). Con este nuevo modelo POJO, ya no necesitará crear un DTO para cada entidad o para un conjunto de entidades … Si desea enviar las entidades EJB 3.0 a través del nivel, simplemente implemente java.io.Serialiazable

No creo que los DTO sean un antipatrón per se, pero existen antipatrones asociados con el uso de los DTO. Bill Dudney se refiere a la explosión de DTO como un ejemplo:

http://www.softwaresummit.com/2003/speakers/DudneyJ2EEAntiPatterns.pdf

También hay una serie de abusos de DTO mencionados aquí:

http://anirudhvyas.com/root/2008/04/19/abuses-of-dto-pattern-in-java-world/

Se originaron debido a los sistemas de tres niveles (que generalmente utilizan EJB como tecnología) como un medio para pasar datos entre niveles. La mayoría de los sistemas modernos de Java basados ​​en frameworks como Spring toman una vista simplificada alternativa usando POJOs como objetos de dominio (a menudo anotados con JPA, etc …) en un único nivel … El uso de DTO aquí es innecesario.

Los puristas de OO dirían que DTO es antipatrón porque los objetos se convierten en representaciones de tabla de datos en lugar de objetos de dominio real.

Algunos consideran que los DTO son un antipatrón debido a sus posibles abusos. A menudo se usan cuando no deberían ser / no deben serlo.

Este artículo describe vagamente algunos abusos.

Si está construyendo un sistema distribuido, entonces las DTO ciertamente no son un patrón anti. No todos se desarrollarán en ese sentido, pero si tiene una aplicación Open Social (por ejemplo), todas se ejecutan en JavaScript.

Publicará una carga de datos en su API. Esto se deserializa en algún tipo de objeto, normalmente un objeto DTO / Solicitud. Esto puede validarse para garantizar que los datos ingresados ​​sean correctos antes de convertirse en un objeto modelo.

En mi opinión, se ve como un antipatrón porque no se utiliza correctamente. Si no construyes un sistema distribuido, es probable que no los necesites.

DTO se convierte en una necesidad y no en un ANTI-PATRÓN cuando tienes todos tus objetos de dominio cargando objetos asociados EAGERly.

Si no crea DTO, tendrá objetos innecesarios transferidos desde su capa empresarial a su cliente / capa web.

Para limitar la sobrecarga para este caso, más bien transfiera los DTO.

La intención de un Objeto de Transferencia de Datos es almacenar datos de diferentes fonts y luego transferirlos a una base de datos (o Fachada Remota ) a la vez.

Sin embargo, el patrón de DTO viola el Principio de Responsabilidad Individual , ya que el DTO no solo almacena datos, sino que también los transfiere desde o hacia la base de datos / fachada.

La necesidad de separar los objetos de datos de los objetos comerciales no es un antipatrón, ya que probablemente sea necesario separar la capa de la base de datos de todos modos.

En lugar de DTO, debe usar Patrones de agregado y repository, que separa la colección de objetos ( Agregado ) y la transferencia de datos ( Repositorio ).

Para transferir un grupo de objetos, puede usar el patrón Unidad de trabajo , que contiene un conjunto de repositorys y un contexto de transacción; para transferir cada objeto en el agregado por separado dentro de la transacción.

Creo que la gente quiere decir que podría ser un anti-patrón si implementa todos los objetos remotos como DTO. Una DTO es simplemente un conjunto de atributos y si tiene objetos grandes, siempre transferiría todos los atributos, incluso si no los necesita o los usa. En este último caso, prefiera usar un patrón Proxy.

La pregunta no debe ser “por qué”, sino ” cuándo “.

Definitivamente es antipatrón cuando solo el resultado de usarlo tiene un costo mayor : tiempo de ejecución o mantenimiento. Trabajé en proyectos que tenían cientos de DTO idénticos a las clases de entidad de base de datos. Cada vez que quería agregar un solo campo, su anuncio se agregaba como cuatro veces: a DTO, a entidad, a la conversión de DTO a clases de dominio o entidades, la conversión inversa, … Olvidó algunos de los lugares y datos obtenidos inconsistente.

No es anti-patrón cuando realmente se necesita una representación diferente de las clases de dominio : más plano, más rico, más estrecho, …

Personalmente empiezo con la clase de dominio y la paso, con el control adecuado en los lugares correctos. Puedo anotar y / o agregar algunas clases de “ayuda” para hacer asignaciones, bases de datos, formatos de serialización como JSON o XML … Siempre puedo dividir una clase en dos si lo necesito.

Se trata de su punto de vista: prefiero ver un objeto de dominio como un solo objeto que desempeña varias funciones, en lugar de múltiples objetos creados el uno del otro. Si la única función que tiene un objeto es transportar datos, entonces es DTO.

    Intereting Posts