c# - usuario - técnicas para manejar clientes difíciles
¿Cuál es la mejor práctica para enviar datos al cliente: POCO o DTO? (4)
Estoy empezando un proyecto usando EF 4 y POCO.
¿Cuál es la mejor práctica para enviar datos al cliente? ¿Debo enviar el POCO o debo 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 el POCO a la capa cliente?
Creo que estamos mezclando 2 definiciones aquí 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 tampoco tienen comportamiento. Martin Fowler explica esto muy bien en: http://www.martinfowler.com/eaaCatalog/dataTransferObject.html
Por otro lado tenemos POCO u objeto CLR antiguo liso. Pero para hablar de POCO, tenemos que saber dónde comenzó, es decir, 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
Así que los POCO pueden tener comportamiento y todo lo que quieras. Son las mismas clases comunes que escribes en su base diaria, solo les dieron ese nombre para que las llamen de una manera breve y fácil de recordar.
En respuesta a su segunda pregunta, creo que el mejor enfoque y el que siempre busco es enviar DTO desde Busines Layer a todo lo que lo use (por ejemplo: sus servicios, sitio web, aplicación de escritorio, aplicación móvil, etc.). Esto se debe a que no tienen comportamiento y no son más que propiedades en la mayoría de los casos, por lo que son livianos e ideales para usar en servicios y, por supuesto, no revelan datos confidenciales de su negocio.
Dicho esto, si planea usar DTO, le recomiendo que descargue EntitiesToDTOs, un generador de DTO de Entity Framework que acabo de publicar en CodePlex, es gratuito y de código abierto. Vaya a http://entitiestodtos.codeplex.com
Para mí, una de las razones principales para usar EF4 con POCO es el hecho de que no necesita DTO. 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 debe ser serializable, pero realmente no debería haber ningún problema específico para el envío de entidades POCO que no ocurran también con los DTO.
Tengo una opinión un poco diferente de las opiniones anteriores. Creo que DTO o ViewModel todavía son necesarios para el lado externo de la capa de servidor. En la aplicación del mundo real, hay una capa de vista que solo necesita un objeto de dominio, es decir, casi todas las vistas necesitan múltiples objetos de dominio. Y todos esos objetos de dominio están envueltos en una clase DTO o ViewModel. Es por esto que insisto en que DTO o ViewModel todavía son necesarios aunque sean POCO.
Yo consideraría los modelos de negocio de las entidades EF4 y los modelos de vista en uno. Ya implementan PropertyChanged fuera de la caja, por ejemplo. Las clases parciales pueden proporcionar una funcionalidad personalizada si es necesario. Reflejar las entidades con su propia capa de seguridad crea un trabajo y un 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 usted. Vete loco.