Entity Framework POCO Change Tracking Strategies

Question

Ho un'applicazione N-Tier in cui le POCO vengono popolate da Entity Framework sul lato server e trasferite alle applicazioni client. I client apportano modifiche ai POCO o aggiungono nuovi POCO e quindi li rimandano al server per essere memorizzati nel database.

Se utilizzo POCO puri, ovvero nessun proxy, non entità di auto-rilevamento, quali sono alcuni degli approcci comuni che le persone stanno adottando per risolvere il problema del rilevamento delle modifiche? Se il tuo servizio riceve una raccolta di POCO, come fa a fare un Add, Update o Delete usando Entity Framework?

Answer 1

Entity Framework non dispone di un buon supporto integrato per tali scenari disconnessi. Sono a conoscenza di tre opzioni:

• Utilizzare GraphDiff, un open source add-on libreria

  Vantaggi

  • alcuna necessità di scrivere il cambiamento codice di monitoraggio sul lato client
  • Modello comune per aggiornare i grafici degli oggetti disconnessi nel database
  • Non molto co de a scrivere sul lato server

  
  Svantaggi

  • database deve essere interrogato e le entità devono essere caricati per rilevare se un oggetto deve essere aggiunto, aggiornati o cancellati
  • Dipendenza su una libreria di terze parti oltre alle librerie principali EF

• grafici aggiornare l'oggetto manualmente sul lato server (Example)

  Vantaggi

  • Non c'è bisogno di scrivere il cambiamento codice di monitoraggio sul lato client
  • No dipendenza da un libreria di terze parti oltre alle librerie di base EF

  
  Svantaggi

  • database deve essere interrogato e le entità devono essere caricati per rilevare se un oggetto deve essere aggiunto, aggiornati o cancellati
  • No modello comune, vale a direla maggior parte degli scenari di aggiornamento richiedono codice individuale
  • Un sacco di codice da scrivere sul lato server

• aggiungere proprietà per gli stati di entità agli oggetti e tenere traccia delle modifiche manualmente sul lato client impostando gli stati di conseguenza (non ho un esempio per questo approccio, credo che Julie Lerman lo stia usando e lo raccomandi)

  Vantaggi

  • Database non deve essere interrogato per rilevare se un oggetto deve essere aggiunto, aggiornati o cancellati
  • Nessuna dipendenza da una libreria di terze parti in aggiunta alle librerie di base EF
  • (Probabilmente?) modello comune sul lato server per tradurre stati cingolati in stati di entità di entità collegate

  
  Disadvan Tages

  • codice di rilevamento delle modifiche per scrivere sul lato client
  • Nessun modello comune sul lato client, vale a dire la maggior parte degli scenari di rilevamento delle modifiche (e tecnologie tipi di client/UI) richiedono codice individuale