2009-02-25 10 views
10

He venido con muchos callejones sin salida en esta pregunta. Supuestamente, .NET 3.5 SP1 tiene soporte para entidades ADO.NET Entity Framework en contratos WCF. Pero cuando busco información sólida, no recibo muchas respuestas. Encontré este fragmento en un hilo de MSDN. ¿Alguien tiene alguna experiencia con esto? ¿Qué pasó con el [DataContract]? ¿Esto es todo lo que hay que hacer? ¿Por qué hay tan poco material sobre esto?WCF Contracts from Entity Framework?

Esta es la respuesta de Tim Mallalieu en Microsoft.

Los tipos de entidad que se generan en Entity Framework son, por defecto, contratos de datos. Si tuviera que crear un modelo simple en Entity Designer como el siguiente: El tipo de entidad de carrito es por defecto un DataContract con todas las propiedades anotadas como miembros de datos. entonces podemos utilizar esto en un servicio WCF de la siguiente manera:

[ServiceContract] 

public interface IService1 

{ 
    [OperationContract] 
    Cart[] AllCarts(); 
} 



public class Service1 : IService1 

{ 
    public Cart[] AllCarts() 

    { 
     using (MSPetShop4Entities context = new MSPetShop4Entities()) 

     { 
      var carts = from c in context.Carts select c; 
      return carts.ToArray(); 
     } 
    } 
} 

A medida que las entidades son DataContracts ahora se puede rodar sus servicios como mejor le parezca y enviar estos a través del cable.

Respuesta

1

Puede ir de la manera más fácil y usar ADO.NET Data Services.

+0

Al final he hecho exactamente eso. Espero que no sea un error a la larga. La desventaja que estoy viendo hasta ahora es que terminé implementando un patrón de repositorio en el lado del cliente y no en el lado del modelo. No estoy contento con eso y probablemente tenga que refactorizar más adelante. – Weej

+0

El peligro de ADO.NET Data Services es que puede ser bastante difícil seguir un enfoque DDD. Debería tratar los Servicios de datos ADO.NET simplemente como eso: servicios de datos. Si necesita un conjunto más sólido de servicios de modelo, deberá crearlo por separado. –

+0

Incluso con la última versión de ADO .NET Data Services y EFCF 4.1, sigue siendo severamente limitante. Por ejemplo, ninguno de los operadores de agregación de LINQ es compatible, incluyendo 'Distinct()'. Si necesita algo más que funciones de CRUD, debe mantenerse alejado de los servicios de datos. – Yuck

6

Recomiendo que no devuelva Entidades directamente. Desafortunadamente, Microsoft eligió incluir datos específicos de la implementación como parte del DataContract para las entidades. Esto no interoperará con otras plataformas, y es el tipo de cosa que podría fallar al interoperar incluso entre versiones de .NET.

En su lugar, le recomiendo que siga el patrón Objeto de transferencia de datos y simplemente devuelva las clases POCO que son copias de los datos en las entidades, sin ningún comportamiento. Puede devolver la Lista de dichas clases para representar una tabla, etc.

+0

Lo he considerado, pero la mente se queda boquiabierta ante la cantidad de trabajo que esto podría ocasionar. A primera vista, el simple código anterior no parece difuminar la separación de las preocupaciones. Si voy a aceptar EF ¿no estoy por un centavo, por una libra? En otras palabras, ya estoy fuera del territorio POCO. ¿No? – Weej

+0

OK John, lo siento, perdí tu punto. Estás diciendo que el objeto que se devuelve tiene 'otras cosas' además de datos simples. Eso no es bueno. ¿Hay alguna buena forma que se te haya ocurrido que genere las declaraciones contractuales del DTO? – Weej

+0

Parte de mí quiere que MS ofrezca un subconjunto de WCF que sea menos interoperable, pero que sea más compatible con Data Entity, Linq, etc, pero que todo eso todavía agrega un acoplamiento que no estoy seguro es una buena idea ... –

3

El principio "compartir interfaces y no escribir" presupone que no posee ambos extremos del cable y/o está escribiendo un mensaje público servicio web. WCF se puede usar (y se usa) en contextos donde esto es decididamente no el caso. Muchas arquitecturas empresariales de n niveles tienen un nivel de aplicación con fachada WCF para facilitar el equilibrio de carga entre otras cosas. En estos casos, es perfectamente válido para compartir el tipo y, de hecho, se desea.

1

algo más de detalle en respuesta a los comentarios:

Hay varios problemas con las clases generadas por EF. Estoy buscando ahora un ejemplo de AdventureWorks con SalesOrderHeader y SalesOrderDetail. La entidad SalesOrderDetail tiene las propiedades "SalesOrderHeader" y "SalesOrderHeaderReference", ambas marcadas como DataMembers. Esto parece un error, ya que la propiedad "SalesOrderHeader" también está marcada [XmlIgnore] y [SoapIgnore].

Además, considere si desea serializar el enlace de nuevo al SalesOrderHeader principal en primer lugar. Además, ¿qué debería ser serializado exactamente? SOAP no admite referencias de manera interoperable.

Finalmente, las clases base de las entidades también son contratos de datos. Sin embargo, no tienen nada que ver con los datos que está devolviendo; son puramente un artefacto de implementación.

En resumen, Microsoft se equivocó en este caso. No lo pensaron bien.

Acerca de las formas de generar las clases de DTO, sugiero buscar en varias herramientas de generación de código, como CodeSmith. Puedes escribir código para hacer esto tú mismo; Lo hice en mi posición anterior.Lo bueno de generar DTO es que también puedes generar los métodos para traducir hacia y desde el DTO.

En cuanto a los gastos generales, la sobrecarga de mover algunos datos en la memoria no es nada comparado con la cantidad de tiempo que va a llevar enviar los datos a través de una red.