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

Question

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.

Me preguntaba por qué fue desde el valor predeterminado EntityObject incluye el [DataContract] atributos e implementos INotifyPropertyChanged. Está devolviendo una clase DTO o POCO mejor que una EntityObject (o Vise Versa)? ¿Y hay instancias específicas en las que es mejor usar un valor de retorno sobre otro?

Answer 1

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

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

Es probable que Microsoft implementó DataContract en EntityObject para admitir algunas de sus herramientas de acceso a la base de datos basadas en WCF como RIA. El inotifypropertychanged es para soporte vinculante de WPF, y no está relacionado con WCF o contratos de datos.

Answer 2

Vale la pena devolver el POCO en algunos casos en los que no consciente de la lógica de persistencia. Me refiero a que el mismo POCO puede enchufarse a otro ORM o para otro propósito. Ok, esta es la ventaja de POCO sobre ORM, pero también le brinda un aumento de rendimiento sobre EntityObject, lo que agrega tiempo de ejecución proxy/notificadores.

Devolviendo POCO: debe actualizar manualmente el estado de la entidad cuando se recibe de WCF.

EntityObject de regreso: recibirá la entidad con el estado mantenido.