Qual è il modo migliore per trasformare un oggetto proxy EF nell'oggetto POCO originale?

Question

Ho alcuni oggetti POCO che sto usando in un codice EF Primo contesto. Quindi, quando li riempio con i dati, mi occupo effettivamente degli oggetti proxy EF piuttosto che degli stessi POCO.

Ho un ApiController ASP.NET MVC4 che restituisce i miei oggetti POCO, che consumerò nella mia applicazione client.

mio "GET" metodo simile a questa:

// 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; 
    } 

che in realtà non funziona, perché quando il serializzatore tenta di serializzare l'oggetto client, in realtà è che fare con la versione delega EF, che provoca a singhiozzo. Vedere Can an ApiController return an object with a collection of other objects?

Così, ho potuto disattivare la generazione di proxy in questo modo al mio DbContext:

db.Configuration.ProxyCreationEnabled = false; 

che assicura che ho a che fare con la POCO piuttosto che un proxy. Ma, ora la maggior parte dei membri della mia classe Client non sono popolati, dal momento che era il proxy EF che faceva il pigro carico di quelli per me.

Quindi quello che voglio veramente è usare la classe proxy EF per ottenere i dati, e poi all'ultimo minuto restituire il POCO originale dal mio metodo.

Come posso farlo senza creare manualmente l'intero oggetto da zero (compresi eventuali oggetti nidificati) nel codice? Sicuramente ci deve essere un modo semplice - o almeno una classe di aiuto di qualche tipo?

Answer 1

La domanda riguarda come progettare l'architettura per un'applicazione. Tecnicamente, esistono più modelli in un'unica applicazione: modello di dominio, oggetto di trasferimento dati o modello di visualizzazione per diversi livelli: livello logico aziendale, livello di distribuzione e livello presentazione.

Utilizzo errato del modello in ASP.NET MVC, vedo spesso utilizzare il modello di dominio (da EF) come modello di vista perché in alcuni casi è corretto che il modello di dominio come modello di visualizzazione sia sufficiente per l'interfaccia utente. Ma in realtà è abbastanza diverso, con l'interfaccia utente complessa, ex: grid, potrebbe essere necessario più di un modello di dominio da combinare in un modello di visualizzazione per fornire dati per l'interfaccia utente.

Simile al livello di distribuzione, asp.net web api, i consumatori potrebbero aver bisogno di più di un modello di dominio per fare qualcosa. Di solito non è un modello di dominio al 100% come oggetto di trasferimento dati.

Quindi, per la separazione di preoccupazione, è consigliabile creare e separare oggetto DTO con oggetto dominio (oggetto POCO da EF), anche se è mappato 1: 1 nelle proprietà.

Esempio: se si dispone del modello di dominio Cliente, è necessario disporre di CustomerDto.

È possibile eseguire la mappatura manuale o utilizzare lo strumento come AutoMapper, per associare il modello di dominio al modello DTO.

Con questo modo è anche possibile evitare i problemi.

Answer 2

ho saputo che avete ottenuto la risposta, ma, può essere che si vuole dare un'occhiata a questo:

Il tipo di proxy POCO non può essere direttamente serializzato o deserializzato dal Windows Communication Foundation (WCF) , poiché il motore di serializzazione DataContractSerializer può serializzare e deserializzare solo tipi noti.Il tipo di proxy non è un tipo noto. Per ulteriori informazioni, vedere la sezione Serializzazione dei proxy POCO nell'argomento Utilizzo delle entità POCO. Per serializzare i proxy POCO come entità POCO, utilizzare la classe ProxyDataContractResolver per mappare i tipi di proxy ai tipi POCO durante la serializzazione.

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