Objeto CLR simple antiguo frente a objeto de transferencia de datos

POCO = Objeto simple de CLR antiguo (o mejor: Clase)

DTO = Objeto de transferencia de datos

En este post hay una diferencia, pero francamente la mayoría de los blogs que leo describen POCO en la forma en que se define DTO: los DTO son contenedores de datos simples que se usan para mover datos entre las capas de una aplicación.

¿Son POCO y DTO lo mismo?

Un POCO sigue las reglas de OOP. Debe (pero no tiene que) tener estado y comportamiento. POCO proviene de POJO, acuñado por Martin Fowler [ anécdota aquí ]. Usó el término POJO como una forma de hacerlo más sexy para rechazar las implementaciones pesadas de EJB. POCO debe usarse en el mismo contexto en .Net. No permita que los marcos dicten el diseño de su objeto.

El único propósito de un DTO es transferir el estado, y no debe tener ningún comportamiento. Vea la explicación de Martin Dowler de un DTO para un ejemplo del uso de este patrón.

Aquí está la diferencia: POCO describe un enfoque de progtwigción (buena progtwigción orientada a objetos a la antigua), donde DTO es un patrón que se usa para “transferir datos” utilizando objetos.

Si bien puede tratar las POCO como DTO, usted corre el riesgo de crear un modelo de dominio anémico si lo hace. Además, existe una falta de coincidencia en la estructura, ya que los DTO deben diseñarse para transferir datos, no para representar la verdadera estructura del dominio comercial. El resultado de esto es que los DTO tienden a ser más planos que tu dominio real.

En un dominio de una complejidad razonable, casi siempre es mejor crear POCO de dominio por separado y traducirlos a DTO. DDD (diseño impulsado por el dominio) define la capa anticorrupción (otro enlace aquí , pero lo mejor es comprar el libro ), que es una buena estructura que hace que la segregación sea clara.

Probablemente sea redundante para mí contribuir ya que ya mencioné mi posición en el artículo de mi blog, pero el último párrafo de ese artículo resume las cosas:

Entonces, en conclusión, aprende a amar al POCO y asegúrate de no difundir ninguna información errónea acerca de que sea lo mismo que un DTO. Los DTO son contenedores de datos simples que se usan para mover datos entre las capas de una aplicación. Las POCO son objetos comerciales de pleno derecho con el requisito de que sean Persistencia Ignorantes (sin métodos de obtención o guardado). Por último, si aún no ha revisado el libro de Jimmy Nilsson, recójalo en las stacks de su universidad local. Tiene ejemplos en C # y es una gran lectura.

Por cierto, Patrick. Leí el POCO como un artículo de Lifestyle, y estoy completamente de acuerdo, es un artículo fantástico. En realidad, es una sección del libro de Jimmy Nilsson que recomendé. No tenía idea de que estaba disponible en línea. Su libro realmente es la mejor fuente de información que he encontrado en POCO / DTO / Repository / y otras prácticas de desarrollo de DDD.

POCO es simplemente un objeto que no depende de un marco externo. Es simple.

Si un POCO tiene un comportamiento o no es inmaterial.

Un DTO tal vez un POCO como un objeto de dominio (que normalmente sería rico en comportamiento)

Por lo general, los DTO tienen más probabilidades de tomar dependencias de marcos externos (por ejemplo, atributos) con fines de serialización, ya que normalmente salen en el límite de un sistema.

En architectures de estilo Cebolla típicas (a menudo se usan dentro de un enfoque ampliamente DDD), la capa de dominio se coloca en el centro y, por lo tanto, sus objetos no deberían tener dependencias fuera de esa capa en este punto.

Escribí un artículo para ese tema: DTO vs Value Object vs POCO .

En breve:

  • DTO! = Objeto de valor
  • DTO ⊂ POCO
  • Objeto de valor ⊂ POCO

Creo que un DTO puede ser un POCO. DTO es más sobre el uso del objeto, mientras que POCO es más del estilo del objeto (desacoplado de los conceptos arquitectónicos).

Un ejemplo en el que un POCO es algo diferente a DTO es cuando habla de POCO dentro de su modelo de dominio / modelo de lógica de negocios, que es una buena representación de OO de su dominio problemático. Puede usar POCO’s durante toda la aplicación, pero esto podría tener algunos efectos secundarios indeseables, tales como filtraciones de conocimiento. Los DTO se usan por ejemplo de la capa de servicio con la que se comunica la UI, los DTO son una representación plana de los datos y solo se usan para proporcionar datos de la UI y comunicar los cambios a la capa de servicio. La capa de servicio está a cargo de mapear los DTO en ambos sentidos a los objetos de dominio POCO.

Actualización Martin Fowler dijo que este enfoque es un camino difícil de tomar, y solo debería tomarse si existe una falta de correspondencia significativa entre la capa de dominio y la interfaz de usuario.

aquí está la regla general: DTO == maldad e indicador de software sobre-diseñado. POCO == bien. Los patrones ’empresariales’ han destruido los cerebros de mucha gente en el mundo de Java EE. por favor no repita el error en .NET land.

Un caso de uso principal para un DTO es el retorno de datos de un servicio web. En este caso, POCO y DTO son equivalentes. Cualquier comportamiento en el POCO se eliminará cuando se devuelva desde un servicio web, por lo que realmente no importa si tiene o no un comportamiento.

Las clases de DTO se usan para serializar / deserializar datos de diferentes fonts. Cuando desee deserializar un objeto de una fuente, no importa qué fuente externa sea: servicio, archivo, base de datos, etc., puede que solo desee utilizar una parte de eso, pero desea una manera fácil de deserializar esa información a una objeto. después de eso, copie esos datos al XModel que desea usar. Un serializador es una tecnología hermosa para cargar objetos DTO. ¿Por qué? solo necesita una función para cargar (deserializar) el objeto.

Ni siquiera los llames DTOs. Se llaman Modelos … Periodo. Los modelos nunca tienen comportamiento. No sé a quién se le ocurrió este tonto término DTO, pero debe ser .NET es todo lo que puedo imaginar. Piense en ver modelos en MVC, en la misma represa **, los modelos se usan para transferir estados entre las capas del lado del servidor o durante el período del cable, todos son modelos. Propiedades con datos Estos son modelos que pasas por el cable. Modelos, Modelos Modelos. Eso es.

Deseo que el estúpido término DTO desaparezca de nuestro vocabulario.