Gli oggetti Moving Entity Framework su un webservice sono davvero il modo migliore?

Non c'è dubbio che potresti ottimizzare questa applicazione - qualsiasi applicazione può essere ottimizzata. Ma prima di immergerti sei sicuro di doverlo fare? C'è un problema con il processo attuale: è troppo lento, troppo costoso, qualcuno si lamenta? Se lo stai facendo solo come miglioramento iterativo e amp; immagina di essere un eroe se puoi ridurre il trasferimento dei dati del 30%, i rischi sono molto più grandi dei benefici. Riscrivere i contratti di servizio significa che dovrai aggiungere codice di trasformazione a ciascuna estremità, il che significa reidratare gli oggetti EF e assicurarti che abbiano lo stato corretto per ricollegarsi al contesto dei dati. Sembra facile ma è un grande cambiamento.

Dovresti assolutamente definire quanto costano gli oggetti EF rispetto agli equivalenti DTO. Stai correndo su un sospetto al momento. Quanti dati verranno salvati apportando questa modifica?

Ci sono miglioramenti più semplici e più ovvi? Quando ho ottimizzato i servizi WCF in passato, ho notato che un enorme sovraccarico nelle dimensioni delle richieste di servizio era rappresentato dalle intestazioni di autenticazione di Windows: enormi token di sicurezza passati tra client e server, che possono essere sostituiti con un certificato molto più piccolo. Tutti i dati inviati sono completamente necessari? Presumo che tu stia inviando binari (net.tcp) piuttosto che testo (http), ma se non lo sei è un ovvio miglioramento.

I DTO sono uno schema utile e sono ampiamente sostenuti da MVC, ma questo non dipende da alcun problema di salvataggio dei dati: è perché forniscono un'interfaccia di servizio, un'astrazione dal database. Senza un DTO si aggiunge una dipendenza al modello del database. Questo non si applica nel tuo caso perché sembra che tu abbia lo stesso modello di database su entrambe le estremità. L'approccio più semplice sarà quello di inviare gli oggetti EF sul filo e inserirli direttamente, proprio come al momento.

Ridurre il traffico di dati farà risparmiare un po 'di soldi. Quanti soldi? Abbastanza per garantire il tempo a sviluppare questa soluzione, tempi di manutenzione aggiuntivi dovuti alla maggiore complessità delle applicazioni?

È possibile utilizzare alcuni oggetti Data Transfer Objects (DTO) solo per trasferire oggetti dai client al server e viceversa. Ovviamente la struttura di questi oggetti leggeri dovrebbe essere condivisa dal sistema (client) per avere la possibilità di serializzare e deserializzare. Questo approccio viene comunemente utilizzato per ridurre la quantità di dati trasferiti e per evitare l'esposizione del dominio.

Immagino che la tua attuale implementazione sia così che gli oggetti del dominio siano usati attraverso il sistema e tutti i client siano in grado di capire gli oggetti che ricevono / mandano. Sarebbe lo stesso concetto con DTO.

Questo processo di conversione dei modelli di Domaing in DTO avrà anche un impatto sulle prestazioni, tuttavia è molto più piccolo e probabilmente non è un problema nel tuo contesto.

Nell'Application Layer che sarà responsabile per l'associazione di Domin Models a DTO (e viceversa) puoi usare AutoMapper , che è un biblioteca molto bella per fare questo lavoro.

Direi che trasferire gli oggetti framework entità su WCF è una cattiva idea. Ogni volta che esegui qualsiasi tipo di operazione su un oggetto EF, generalmente si generano chiamate al database. Questo può essere abbastanza grave per le prestazioni quando tutto viene fatto in un unico servizio e l'aggiunta di un livello aggiuntivo sulla connessione di rete rallenterà davvero le cose!

Esiste un concetto / modello chiamato modello DTO (oggetto di trasferimento dati) che comporta la creazione di nuovi tipi più semplici che contengono semplicemente tutte le informazioni che saranno richieste nel client e che passeranno invece.

Quindi crei un Dado Assembler che è responsabile della creazione di DTO dai tuoi modelli di framework di entità.

Googling DTO's si spera possa essere un buon punto di partenza per te. Ecco un link di esempio all'indirizzo MSDN

Sembra che tu stia utilizzando entità di auto-tracciamento e infatti questi oggetti che sono serializzati saranno grandi e non è raccomandato inviare su WCF nel tuo scenario. DTO, come altri hanno menzionato, sarebbe anche la mia opzione preferita. La prossima domanda sarebbe la serializzazione a livello di filo che darà la dimensione più piccola. Un'opzione utilizza protocol-buffer che non ho usato personalmente ma che vale la pena esaminare.
Ma quello che suggerirò è di usare JSON come JSON è significativamente più piccolo di XML equivalente. È possibile utilizzare gli attributi WCF ([WebGet], [WebIvoke]) o meglio ancora utilizzare l'API ASP.Net MVC Web . Abilitare la compressione gzip usando IIS dovrebbe ridurre significativamente le dimensioni del payload.