2012-08-01 15 views
5

Tengo algunos objetos POCO que estoy usando en un contexto de Código EF Primero. Entonces, cuando los llevo con datos, en realidad estoy lidiando con los objetos proxy EF en lugar de los POCOs mismos.¿Cuál es la mejor manera de convertir un objeto proxy EF en el objeto POCO original?

Tengo un ASP.NET MVC4 ApiController que devuelve mis objetos POCO, que consumiré en mi aplicación cliente.

Mi "GET" método es como la siguiente:

// GET api/Clients/5 
    public Client GetClient(int id) 
    { 
     Client client = db.Clients.Find(id); 
     if (client == null) 
     { 
      throw new HttpResponseException(Request.CreateResponse(HttpStatusCode.NotFound)); 
     } 

     return client; 
    } 

que en realidad no funciona, porque cuando el serializador intenta serializar el objeto de cliente, en realidad se trata de la versión proxy de EF, que causa es hipo. Ver Can an ApiController return an object with a collection of other objects?

Por lo tanto, podría desactivar la generación de proxy al hacer esto a mi DbContext:

db.Configuration.ProxyCreationEnabled = false; 

que asegura que estoy tratando con la POCO lugar de un proxy. Pero ahora la mayoría de los miembros de mi clase de Cliente no están ocupados, ya que fue el proxy de EF el que me cargó lazy.

Entonces, lo que realmente quiero es usar la clase de proxy de EF para obtener los datos, y luego en el último minuto devolver el POCO original de mi método.

¿Cómo puedo hacer eso sin crear manualmente el objeto completo desde cero (incluidos los objetos anidados) en el código? Seguramente debe haber una manera fácil, o al menos una clase de ayuda de algún tipo.

Respuesta

3

Su pregunta consiste en cómo diseñar la arquitectura para una aplicación. Técnicamente, hay más de un modelo en una aplicación: modelo de dominio, objeto de transferencia de datos o modelo de vista para diferentes capas: capa de lógica de negocios, capa de distribución y capa de presentación.

Mal uso del modelo en ASP.NET MVC, a menudo uso el modelo de Dominio (desde EF) como modelo de vista porque en algunos casos es correcto que el modelo de dominio como modelo de vista sea suficiente para su UI. Pero en realidad es bastante diferente, con una interfaz de usuario compleja, por ejemplo, una cuadrícula, es posible que necesite combinar más de un modelo de dominio en un modelo de vista para proporcionar datos para su UI.

Similar a la capa de distribución, asp.net web api, los consumidores pueden necesitar más de un modelo de dominio para hacer algo. Por lo general, no es un modelo 100% de dominio como objeto de transferencia de datos.

Por lo tanto, para la separación de la preocupación, se sugiere que debe crear y separar el objeto DTO con el objeto de dominio (objeto POCO de EF), incluso si está mapeado 1: 1 en las propiedades.

Ejemplo, si tiene un modelo de dominio Cliente, necesita tener CustomerDto.

Puede mapear manualmente o utilizar una herramienta como AutoMapper, para asignar su modelo de dominio al modelo DTO.

De esta forma también puede evitar sus problemas.

+2

+1 exponer dtos al cliente remoto es el mejor camino a seguir. Le da un control total sobre los datos enviados a través del cable. –

+0

Gracias, verifico AutoMapper - suena como la clase de "ayudante de algún tipo" que estaba buscando. –

1

sabido que tienes la respuesta, pero, puede ser que tendrá que echar un vistazo a esto:

El tipo de proxy POCO no puede ser directamente en serie o deserializado por el Windows Communication Foundation (WCF) , porque el motor de serialización DataContractSerializer solo puede serializar y deserializar tipos conocidos.El tipo de proxy no es un tipo conocido. Para obtener más información, consulte la sección Serializing POCO Proxies en el tema Trabajar con entidades POCO. Para serializar los proxys POCO como entidades POCO, use la clase ProxyDataContractResolver para asignar tipos de proxy a los tipos POCO durante la serialización.

http://msdn.microsoft.com/en-us/library/vstudio/ee705457(v=vs.100).aspx

+0

Interesante, gracias. –

Cuestiones relacionadas