Linq a Entidades con WCF

Question

Tengo todas mis entidades en un proyecto separado en mi archivo edmx y las expongo a mi aplicación cliente usando un servicio WCF.

Eso significa que no tengo que dar a mi aplicación cliente un enlace directo al proyecto que contiene el archivo edmx. Eso sería malo porque continúa el objeto para consultar la base de datos.

Pero solo se puede acceder a las entidades que utiliza mi servicio WCF desde mi aplicación cliente. Así, por ejemplo, porque tengo el siguiente código en mi servicio:

public MyClass GetMyClass() 
{ 
    return new MyClass(); 
} 

.. Puedo usar MiClase de acceso en mi aplicación cliente con algo como:

myServiceInstance.MyClass cls = new myServiceInstance.MyClass() 

¿Qué pasa si tengo una entidad llamada MyClass2 en mi archivo edmx que quiero usar en mi aplicación cliente Cómo instalarlo sin darle a mi cliente un enlace directo a mi proyecto de archivo edmx o hacer un método inútil en mi capa de servicio que devuelve MyClass2

¿Qué están haciendo otras personas?

Muchas gracias

Answer 1

Si el servicio WCF no usarlo, ¿qué quiere? Un servicio WCF (sí mismo) es puramente para el transporte de datos: el enfoque "mex" para los metadatos no comparte el código, por lo que su MyClass2 sería impotente. Si lo desea, puede usar el ensamblaje compartido en el cliente, pero I realmente no lo recomiendo en este caso; Los objetos EF en el cliente son un desastre ... (además no funcionará en los marcos livianos como Silverlight, Perfil del cliente, Compact Framework, etc.)

Otra opción es ADO.NET Data Services; esto funciona sobre WCF, pero le da una API más amigable para LINQ que el enfoque WCF regular, y cualquier objeto de dominio que expone su modelo debe estar disponible en el contexto de datos del cliente.

Answer 2

hemos creado un proyecto separado con clases de transferencia de objetos de dominio que sirvieron como contratos de datos para nuestros varios servicios WCF internos. Luego compartimos el proyecto de contratos con esos servicios internos. Tuvimos un servicio de datos; esos métodos traducirían estos objetos de dominio a/desde objetos de entidad antes/después de almacenar/recuperar. Mientras tanto, los servicios externos hicieron uso de los proxies estándar generados a partir de archivos XSD y WSDL, y se tradujeron a/del modelo de transferencia de dominio compartido.

Tuvimos que hacer esto porque el contexto del objeto no es (todavía) portátil sobre WCF, desafortunadamente.

Algunas consideraciones para su situación:

1. Si la aplicación cliente es externa a su sistema, no debe saber nada acerca de su EDMX o sus clases. Solo debe saber sobre su WSDL y XSD.
2. Si su aplicación cliente es interna, no sirve de nada intentar compartir las clases de entidad en EF v1 porque aún no se admite adecuadamente. Necesita transferir más que solo las clases/objetos; también necesita el contexto, que mantiene el seguimiento de cambios, y no se puede hacer a través de WCF directamente en este momento.

Answer 3

Si desea hacerlo de la manera "correcta", debe crear clases especiales para sus mensajes que están cruzando el cable, en lugar de tratar de reutilizar entidades comerciales u objetos de datos como mensajes. El valor de esto es que puede cambiar sus entidades comerciales y objetos de datos sin preocuparse por el cambio del contrato que ha expuesto a los consumidores. Cada cambio en su servicio es un poco más deliberado ya que ocurre independientemente de los cambios en los datos y la lógica de negocios.

Otra forma de manejar esto es simplemente usar svcutil (o "Agregar referencia de servicio ..." aunque svcutil funciona mejor para múltiples puntos finales de servicio) para generar todas las clases que el cliente usará en lugar de agregar una referencia a el proyecto de servidor. De esta forma, las únicas clases que su cliente verá serán las expuestas por el servicio.