Estoy comenzando un proyecto usando EF 4 y POCO.¿Cuál es la mejor práctica para enviar datos al cliente: POCO o DTO?
¿Cuál es la mejor práctica para enviar datos al cliente? ¿Debería enviar el POCO o debería tener un DTO en su lugar?
¿Hay algún problema que deba tener en cuenta al enviar la entidad (que está desconectada del contexto) al cliente?
¿Es una práctica recomendada enviar POCO a la capa del cliente?
Para mí, una de las razones principales para usar EF4 con POCO es el hecho de que usted no necesita DTO's. Puedo entender el uso de DTO con archivos EDMX tradicionales donde sus entidades están bastante hinchadas, pero este no es el caso.
Obviamente, su POCO necesita ser serializable, pero realmente no debería haber problemas específicos para el envío de entidades de POCO que tampoco ocurren con los DTO.
¿Entonces exponer el modelo comercial al cliente no es una mala práctica? Para algunos, es una mala práctica exponer el modelo comercial al mundo externo ... ¿qué piensas sobre esto? – pdiddy
Para mí, el POCO debería ser muy ... bueno ... "simple", por así decirlo. Y si ese es el caso, ¿cuál es el daño al enviarlo a un cliente? ¿Cómo se verá tu DTO? ¿Van a reflejar el POCO casi exactamente? Entonces, ¿por qué te pasas por el dolor de cabeza? Los DTO son buenos cuando quieres eliminar un montón de cruces, pero realmente no veo el daño al enviar tus POCO al mundo si no contienen información confidencial que no quieres que se exponga. –
Gracias, supongo que enviaré el objeto POCO. Simplemente tuve la impresión de que era una mala práctica en general. Pero en mi caso, realmente no los estamos exponiendo al mundo externo. Estamos exponiendo a nuestra propia aplicación cliente. – pdiddy
Consideraría los modelos de negocio de las entidades EF4 Y los modelos de vista en uno. Ya implementan PropertyChanged de fábrica, por ejemplo. Las clases parciales pueden proporcionar una funcionalidad personalizada si es necesario. Duplicar las entidades con su propia capa de seguridad crea trabajo y mantenimiento innecesarios, en mi opinión.
Soy un creyente en la separación de la lógica de negocios y todo lo demás. Sin embargo, en el caso de EF4, el trabajo ya está hecho para ti. Enloquece.
Estoy optando por no usar las entidades EF, pero el POCO ya que EF tiene un buen soporte para PI. Pero gracias por tu respuesta. – pdiddy
Creo que aquí estamos mezclando 2 definiciones que no tienen relación entre sí.
DTO o Objeto de transferencia de datos es un patrón de diseño, puede usarlo para transferir datos entre capas, y también no tienen ningún comportamiento. Martin Fowler lo explica muy bien en: http://www.martinfowler.com/eaaCatalog/dataTransferObject.html
Por otro lado tenemos POCO o Plain Old CLR Object. Pero para hablar de POCO, tenemos que saber dónde comenzó, es POJO o Plain Old Java Object. Martin Fowler con dos socios acuñó el término y lo explica aquí: http://www.martinfowler.com/bliki/POJO.html
Por lo tanto, los POCO pueden tener un comportamiento y todo lo que desee. Son las mismas clases comunes que escribes en tu día a día, simplemente les dieron ese nombre para llamarlas de una manera corta y fácil de recordar.
En respuesta a su segunda pregunta, creo que el mejor enfoque y el que siempre busco es el envío de DTO de la capa de negocio a todo lo que lo utiliza (por ejemplo: sus servicios, sitio web, aplicación de escritorio, aplicación móvil, etc.). Esto se debe a que, en la mayoría de los casos, no tienen un comportamiento y no son solo propiedades, por lo que son livianos e idealmente utilizados en los servicios, y por supuesto, no revelan datos confidenciales de su empresa.
Dicho esto, si está planeando utilizar DTO, puedo recomendarle que descargue EntitiesToDTOs, un generador de DTO de Entity Framework que recientemente publiqué en CodePlex, es de código abierto y gratuito. Vaya a http://entitiestodtos.codeplex.com
Tengo una opinión un poco diferente de las opiniones anteriores. Creo que todavía se necesita DTO o ViewModel para el lado externo de la capa del servidor. En la aplicación del mundo real, hay algunas capas de vista que solo necesitan un objeto de dominio, es decir, casi todas las vistas necesitan múltiples objetos de dominio. Y todos esos objetos de dominio se envuelven en una clase DTO o ViewModel. Es por eso que insisto que todavía se necesita DTO o ViewModel aunque sean POCO.
¿Y qué pasa con las Entidades de seguimiento personal? Pueden ahorrarle mucho trabajo adicional para insertar, actualizar y eliminar operaciones del lado del servidor. No crea que los poco tienen esta funcionalidad. Y les aconsejo que lean el "Marco de Entidades de Programación" de Julie Lerman. Explora todo tipo de opciones, incluidas las entidades de poco, dto y seguimiento propio. –