2013-09-27 20 views
6

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.Entity Framework POCO Change Tracking Strategies

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?

risposta

6

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