Quali sono i pro e i contro dell'utilizzo di uno o più DbContext con EF?

Question

VS2013, codice EF6 prima, MVC, (VB)

Volevo comprendere meglio i pro e i contro dell'utilizzo di un singolo contesto o della divisione di DbSet in più contesti. Ho letto alcuni vecchi messaggi SO su più DbContexts e non ho trovato veramente quello che stavo cercando; una dichiarazione completa su quando e dove usare o non usare più DbContexts.

Nel caso di un singolo utente che esegue un programma come Windows Form sul proprio hardware, sembrerebbe che non vi sia motivo di avere più contesti per facilitare il lavoro con il codice.

Nel caso di un'applicazione Web che esegue un importante programma aziendale per più aziende, sembrerebbe che più DbContexts siano essenziali per la sicurezza e l'amministrazione.

Ma mi piacerebbe avere una conferma se sto pensando a questa domanda correttamente. Tutto quello che posso pensare è il seguente, ma poi io sono abbastanza nuovo a questo ambiente:

A favore di un unico contesto:

• Coding ha solo un unico contesto per affrontare
  • (ci sono problemi con le relazioni attraverso contesti?)
• Le migrazioni sono più facili perché non v'è una sola cartella di migrazione e di processo
• più facile ottenere un completo d iagram costruito in SSMS o EDMX
  • (Link here per ottenere diagrammi EDMX quando si utilizza il codice prima)

Contro di un unico contesto:

• sicurezza potrebbe essere un problema per il multiplo web clienti in un'app aziendale
  • (Si tratta di un problema per i siti Web semplici che hanno iscrizioni semplici?)
• alcuni così i messaggi sembrano suggerire il tempo di risposta è un problema
  • (Qual è il meccanismo qui?)

Questo è tutto quello che ho. Non ne so abbastanza per comprendere appieno le due parti, e dato i diversi ambienti in cui possiamo lavorare, sembrerebbe che la risposta a uno o più contesti sarà diversa.

Attualmente sto lavorando a un sito Web che avrà iscrizioni e anche un'app scaricabile che sarà un'app personale in esecuzione sull'hardware dell'utente. In questo caso, penso che un singolo contesto per entrambi abbia senso, ma prima di approfondirmi, vorrei però chiedere una discussione su questo. Presumo che altri che sono in qualche modo nuovi per l'ambiente continueranno ad avere le stesse domande.

Ho anche notato che Microsoft ha ritenuto opportuno aggiungere più funzionalità di contesto all'EF in EF6 e versioni successive, quindi è chiaro che ci devono essere alcuni ambienti di programmazione che danno origine a motivi convincenti per avere più contesti.

Grazie per l'input.

migliori saluti, Alan

Answer 1

L'unica buona ragione per avere molteplici contesti, a mio parere, è se si dispone di più database in gioco. Ad esempio, un'applicazione con cui lavoro ha 3 contesti. Due contesti sono per database esistenti di cui l'applicazione non è direttamente responsabile, mentre il terzo è il contesto specifico dell'applicazione con le migrazioni.

Non c'è alcun vantaggio reale nella suddivisione di un contesto. Erik suggerisce che i contesti di grandi dimensioni hanno problemi di prestazioni, ma ho lavorato con un singolo contesto con oltre 50 insiemi di oggetti e non ho notato alcun problema di prestazioni.

Tuttavia, sul rovescio della medaglia, ci sono reali svantaggi nel lavorare con più contesti. Per uno, perdi la capacità di lavorare con più oggetti senza problemi a meno che non risiedano tutti nello stesso contesto. Inoltre, i contesti multipli tendono a confondere gli sviluppatori verdi a causa del tracciamento del grafo degli oggetti di Entity Framework. Ad esempio, supponiamo che tu abbia due entità, Foo e Bar, entrambe in contesti separati. Se si è creato un rapporto di Bar su Foo:

public class Foo 
{ 
    public virtual Bar Bar { get; set; } 
} 

Bene, indovinate un po '? Entrambi FooeBar sono ora tracciati dal contesto di Foo. Se provi a eseguire le migrazioni in entrambi i contesti, riceverai errori perché Bar è gestito in due, conteggi, due contesti.

Errori come questo sono incredibilmente facili da realizzare e ti farai impazzire cercando di tenere tutto totalmente escluso. Inoltre, la mia argomentazione è sempre stata che se hai entità nel tuo progetto che puoi escludere completamente dagli altri, allora questo è un argomento per un progetto completamente separato, non solo un contesto diverso.

Answer 2

Ho visto nei commenti che hai citato l'apprendimento di Domain Driven Design. Uno dei concetti in DDD è quello di Bounded Contexts (accertarsi di controllare la risorsa collegata su bubble contexts per vedere come gestire due contesti che condividono entità).

Effettua assoluto senso per mappare i contesti limitati utilizzando un DbContext separato per ciascuno. Ci sono alcuni trucchi che devi fare attenzione quando lo fai, ma seguire un approccio DDD dovrebbe aiutarti a evitarli. Il primario è entità condivise. Un contesto dovrebbe essere responsabile del controllo del ciclo di vita delle entità condivise, l'altro dovrebbe solo interrogare quelle entità e non apportare alcuna modifica ad esse.

La separazione del dominio in contesti limitati consente di gestire più facilmente un dominio grande/complesso. Evita anche di caricare inutilmente parti del dominio se non ne hai bisogno (in una SOA, puoi distribuire autonomamente ciascun contesto limitato come servizio che Udi Dahan chiama uno Autonomous Business Component).

Non vorrei sostenere la divisione fino a quando non è necessario. Ad esempio, più team che lavorano contemporaneamente con diverse parti del dominio potrebbero presentare una buona opportunità per effettuare la suddivisione, ma a un certo punto avrà sicuramente senso farlo.