¿Debería un servicio WCF devolver un objeto EntityObject o una clase POCO/DTO?

He estado buscando muchos ejemplos de WCF usando EntityFramework y la mayoría de ellos parecen devolver algún tipo de clase POCO o DTO al cliente.¿Debería un servicio WCF devolver un objeto EntityObject o una clase POCO/DTO?

Me preguntaba por qué esto fue porque el valor predeterminado EntityObject incluye los atributos [DataContract] e implementa INotifyPropertyChanged. ¿Devolver una clase DTO o POCO mejor que un EntityObject (o viceversa)? ¿Y hay instancias específicas donde es mejor usar un valor de retorno sobre otro?

Fuente

2011-01-28 Rachel

posible duplicado de [WCF, Entity Framework & Data Contracts] (http://stackoverflow.com/questions/1121877/wcf-entity-framework-data-contracts) –

Como una buena práctica, definitivamente debe hacer que devuelva una clase DTO/POCO explícitamente diseñada como un contrato de datos y no tiene lógica de persistencia.

La razón es que si pasa un EntityObject, supone que el consumidor del servicio tendrá una referencia al mismo contexto de datos, y esto infringe el principio SOA de los límites explícitos. Reduce la reutilización de su servicio.

Es probable que Microsoft haya implementado DataContract en EntityObject para admitir algunas de sus herramientas de acceso a bases de datos basadas en WCF como RIA. INotifyPropertyChanged es para compatibilidad de enlace WPF, y no está relacionado con WCF o contratos de datos.

Fuente

2011-01-28 02:01:06

Gracias. ¿Es habitual devolver el DTO al EntityObject en el Cliente o se prefiere crear un nuevo Modelo para los fines del cliente? – Rachel

Obviamente, esto depende de su arquitectura, pero si el cliente tiene una copia local de la base de datos, puede convertir el DTO de nuevo en EntityObject. El punto es mantener el contrato limpio para que el servicio no implique ninguna implementación específica, solo proporciona los datos en un formato estándar. –

El cliente solo debe trabajar con DTO que es del tipo proporcionado por el servicio que consume y es más simple, por supuesto. A menos que tenga la necesidad de utilizar el contexto en el cliente con todas las características de las entidades por algún motivo (lo cual dudo porque es un cliente ¿verdad?). – kzfabi

Vale la pena devolver el POCO en algunos casos donde no conoce la lógica de persistencia. Me refiero a que el mismo POCO puede conectarse a otro ORM o para otro propósito. De acuerdo, esta es una ventaja de POCO sobre ORM, pero también le da un impulso de rendimiento sobre EntityObject, que agrega tiempo de ejecución proxy/notificadores.

Devolución de POCO: debe actualizar manualmente el estado de la entidad cuando se recibe desde WCF.

EntityObject devuelto - Usted recibe la entidad con estado mantenido.

Fuente

2011-01-28 05:43:38 paragy

¿Debería un servicio WCF devolver un objeto EntityObject o una clase POCO/DTO?

Respuesta

Cuestiones relacionadas