Plain Old CLR Object vs transferencia de datos de objetos

Question

POCO = Plain Old CLR (o mejor: Class) Object

DTO = Transferencia de datos de objetos

En este href="http://rlacovara.blogspot.com/2009/03/what-is-difference-between-dto-and-poco.html" hay una diferencia, pero francamente la mayoría de los blogs que leo describir POCO en la forma DTO se define:. DTOs son contenedores de datos simples que se usan para mover datos entre las capas de una aplicación

Son POCO y DTO lo mismo?

Answer 1

A POCO sigue las reglas de programación orientada a objetos. Debería (pero no tiene que) tienen estado y comportamiento. POCO proviene de POJO, acuñado por Martin Fowler [ anécdota aquí ]. Usó el término POJO como una manera de hacerlo más atractivo para rechazar las implementaciones EJB marco pesado. POCO se debe utilizar en el mismo contexto en .Net. No deje que los marcos dictan el diseño de su objeto.

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

Aquí está la diferencia: POCO describe un enfoque de la programación (buen aspecto antiguo programación orientada a objetos), donde DTO es un patrón que se utiliza para "transferencia de datos" utilizando objetos.

Si bien se puede tratar como POCOs dtos, se corre el riesgo de crear un modelo de dominio anémico si lo hace. Adicionalmente, hay una falta de coincidencia en la estructura, ya que dtos deben ser diseñados para transferir datos, no para representar la verdadera estructura del dominio de negocio. El resultado de esto es que las organizaciones narcotraficantes tienden a ser más plana que su dominio real.

En un dominio de cualquier complejidad razonable, usted es casi siempre mejor crear dominio separado POCOs y traducirlos a dtos. DDD (impulsada por el diseño de dominio) define el anti-corrupción capa (otro enlace aquí , pero mejor que puede hacer es comprar el libro), que es una buena estructura que hace que la segregación clara.

Answer 2

Es probable que sea redundante para mí para contribuir desde ya dije mi posición en mi artículo de blog, pero el último párrafo de dicho artículo sumas tipo de cosas:

Así que, en conclusión, aprender a amar la POCO, y asegúrese de que no se derrame cualquier información errónea acerca de que sea el mismo que un DTO. DTOs son contenedores de datos simples que se usan para mover datos entre las capas de una aplicación. POCOs están llenos de objetos de negocio desarrollado, con el único requisito de que son Persistencia ignorante (sin get o guardar métodos). Por último, si usted no ha obtenido el libro de Jimmy Nilsson, sin embargo, recoger de sus pilas de la universidad local. Cuenta con ejemplos en C # y es una gran lectura.

Por cierto, Patrick leí la POCO como un artículo de estilo de vida, y estoy totalmente 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 es realmente la mejor fuente de información que he encontrado en / DTO / repositorio / y otras prácticas de desarrollo POCO DDD.

Answer 3

POCO es simplemente un objeto que no tiene una dependencia en un marco externo. Está claro.

Ya sea a Poco tiene un comportamiento es o no es irrelevante.

A DTO puede ser POCO como puede un objeto de dominio (que sería típicamente rica en el comportamiento).

Normalmente DTOs son más propensos a tener dependencias en marcos externos (por ejemplo. Los atributos) para fines de serialización como típicamente el que salen en el límite de un sistema.

En las arquitecturas típicas de estilo cebolla (usado a menudo dentro de un enfoque ampliamente DDD) la capa de dominio se coloca en el centro y por lo que sus objetos no debe, en este punto, tener dependencias fuera de esa capa.

Answer 4

escribí un artículo para ese tema: DTO vs vs valor de los objetos POCO .

En resumen:

• DTO! = Valor del objeto
• DTO ⊂ POCO
• Valor Objeto ⊂ POCO

Answer 5

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

Un ejemplo donde un POCO es algo diferente de DTO es cuando se habla sobre Poco dentro de su modelo lógico modelo de dominio / negocio, que es una representación OO agradable de su dominio del problema. Se podría utilizar la POCO del largo de toda la aplicación, pero esto podría tener algún efecto secundario indeseable se producen fugas de tal conocimiento. DTO de son, por ejemplo usado de la capa de servicio que la interfaz de usuario se comunica con, del DTO son representación plana de los datos, y sólo se utilizan para proporcionar la interfaz de usuario con los datos, y comunicar los cambios de nuevo a la capa de servicio. La capa de servicio está a cargo de la cartografía de los dos caminos de la DTO a los objetos de dominio Poco.

Actualizar dijo que este enfoque es un camino pesado a tomar, y sólo debe tomarse si hay una falta de coincidencia significativa entre la capa de dominio y la interfaz de usuario.

Answer 6

Un caso de uso principal de un DTO es en la devolución de los datos de un servicio web. En este caso, POCO y DTO son equivalentes. Cualquier comportamiento en la POCO sería eliminado cuando se volvió de un servicio web, por lo que en realidad no importa si tiene o no tiene el comportamiento.

Answer 7

aquí es la regla general: DTO == mal y el indicador de software de más de la ingeniería. POCO == buena. patrones 'Enterprise' han destruido el cerebro de una gran cantidad de personas en el mundo Java EE. por favor no repetir el error en la tierra .NET.

Answer 8

clases DTO se utilizan para serializar los datos / deserializar de diferentes fuentes. Cuando desee deserializar un objeto a partir de una fuente, no importa qué fuente externa es: servicio, archivo, etc base de datos es posible que sólo desea utilizar una parte de eso, sino que quiere una manera fácil de deserializar que los datos a una objeto. después de que copia los datos al XModel que desea utilizar. Un serializador es una hermosa tecnología para cargar objetos DTO. ¿Por qué? sólo necesita una función para cargar (deserializar) del objeto.

Answer 9

TL; DR:

A DTO describe el patrón de la transferencia de estado. A Poco no describe nada. Es otra forma de decir "objeto" en la programación orientada a objetos. Viene de POJO (Java), acuñado por Martin Fowler, que literalmente sólo lo describe como un nombre más elegante para el 'objeto', porque 'objeto' no es muy atractiva.

A DTO es un modelo objeto utilizado para transferir estado entre las capas de preocupación. Pueden tener un comportamiento (es decir, puede ser técnicamente un poco), siempre y cuando que el comportamiento no muta el estado. Por ejemplo, puede tener un método que serializa sí mismo.

A POCO es un objeto simple, pero ¿qué se entiende por 'normal' es que no es especial. Sólo significa que es un objeto CLR sin un patrón implícita a ella. Es un término genérico. No está hecho para trabajar con algún otro marco. Así que si su POCO ha [JsonProperty] o decoraciones EF todo sus propiedades, por ejemplo, entonces yo diría que no es un POCO.

A continuación, algunos ejemplos de diferentes tipos de patrones de objetos para comparar:

• Ver Modelo : se utiliza para modelar los datos de una vista. Por lo general, tiene anotaciones de datos para ayudar a la unión y la validación. En MVVM, que también actúa como un controlador. Es más que un DTO
• Valor de objetos : se utiliza para representar los valores
• Agregada raíz : se utiliza para administrar el estado y invariantes
• Manipuladores : se utiliza para responder a un evento / mensaje
• Atributos : se utiliza como decoraciones para hacer frente a las preocupaciones transversales
• Servicio : se utiliza para realizar tareas complejas
• Controller : se utiliza para controlar el flujo de solicitudes y respuestas
• Fábrica : se utiliza para configurar y / o ensamblar objetos complejos para su uso cuando un constructor no es lo suficientemente bueno. También se utiliza para tomar decisiones sobre la que se deben crear objetos en tiempo de ejecución.
• Repositorio / DAO : se utiliza para acceder a los datos

Estos son todos los objetos solo, pero notan que la mayoría de ellos están ligados generalmente a un patrón. Así se les puede llamar "objetos" o podría ser más específico sobre su intención y lo llama por lo que es. Esta es la razón por la que tenemos patrones de diseño; para describir conceptos complejos en algunas obras. DTO es un patrón. raíz agregado es un patrón, Ver Modelo es un patrón (por ejemplo MVC y MVVM). POCO no es un patrón.

A Poco no describe un patrón. Es sólo una manera diferente de hacer referencia a las clases / objetos en programación orientada a objetos. Piense en ello como un concepto abstracto; que pueden estar refiriéndose a nada. OMI, hay una relación unidireccional, porque aunque una vez que un objeto llega al punto en el que sólo puede servir a un propósito limpiamente, que ya no es un POCO. Por ejemplo, si usted marca encima de su clase con decoraciones para hacer que funcione con algún tipo de marco, ya no es un POCO. Por lo tanto:

• A DTO es un POCO
• A Poco No es un DTO
• una vista de modelo es un POCO
• A Poco No es una vista de modelo

El sentido hacer una distinción entre los dos es acerca de mantener los patrones clara y consistente en el esfuerzo para no cruzar las preocupaciones y dar lugar a un acoplamiento apretado. Por ejemplo, si tiene un objeto de negocio que tiene métodos para mutar estado, sino que también está decorado al diablo con decoraciones de EF para guardar en SQL Server y JsonProperty para que pueda ser enviado de vuelta a través de un punto final de la API. Ese objeto sería intolerante a cambiar, y probablemente se llena de variantes de propiedades (por ejemplo, identificación de usuario, UserPk, USERKEY, UserGuid, donde algunos de ellos están marcados hasta no se guardarán en la base de datos y otros marcado para no ser serializado a JSON en el punto final API).

Así que si usted fuera a decirme algo era un DTO, entonces probablemente me aseguro de que nunca fue utilizado para otra cosa que en estado movido alrededor de cualquier cosa. Si usted me dijo algo que era un modelo de vista, entonces probablemente me aseguro de que no se estaba guardada en una base de datos. Si usted me dijo algo que era un modelo de dominio, entonces probablemente me aseguro de que haD No dependencias en cualquier cosa fuera del dominio. Pero si usted me dijo que algo estaba a poco, en realidad no se me dirá mucho a todos.

Answer 10

Ni siquiera los llaman dtos. Se llaman Modelos .... Período. Modelos nunca tienen comportamiento. No sé que ocurrió esta DTO tonto plazo, pero debe ser una cosa .NET es todo lo que puedo imaginar. Piense de Visualización de modelos en MVC, misma presa ** cosa, los modelos se utilizan para transferir el estado entre lado del servidor capas o durante el período de alambre, que son todos los modelos. Las propiedades con los datos. Estos son los modelos que pasas ove el alambre. Modelos, Modelos modelos. Eso es.

Me gustaría que el término estúpida DTO se fuera de nuestro vocabulario.