2015-08-29 4 views
10

Nel framework C# MVC EF, ho visto molti esempi che creano semplicemente un nuovo DbContext ogni volta che è necessario inserire un inserto o una query e quindi chiuderlo/rilasciarlo (molti usano "using" per auto close/release).DbContext è un'operazione costosa?

Si è cercato su questo ma non è stato possibile trovare una buona risposta, ma sta creando un DbContext un'operazione molto economica e veloce?

Ad esempio, se si pensa a un'applicazione MVC tipica, nella pagina sono presenti molti "componenti", come intestazioni, barre del sider, contenuto principale, ecc. E in una configurazione non banale, ogni componente avrà il suo proprio logica e codice personale - suppongo di creare un nuovo DbContext in ognuno di questi componenti? (in caso affermativo, il sistema memorizza automaticamente nella cache il risultato della query? Ad esempio, un caso d'uso comune è che, in ciascuno di questi componenti, è necessario interrogare il database per le impostazioni correnti del sito, che è la stessa riga in un tavolo).

+2

Questo è qualcosa * facilmente * testato e osservato da * voi *. Provaci e scoprilo! –

+0

@ Cubicle.Jockey Dove altro dovrebbe fare? Il controller sembra un buon posto. –

+0

Non lo invio come risposta perché non riesco a trovare la pagina originale su MSDN, ma i contesti sono preparati per essere creati e distrutti in modo efficiente, l'unica parte dispendiosa nella creazione di un contesto è la connessione DB sottovoce e EF gestiscilo, non lo chiuderà quando distruggi il contesto, ha un pool interno che li gestisce – Gusman

risposta

10

Come osservato in "Performance Considerations for Entity Framework 4, 5 and 6" sezione 9.3 (sottolineatura mia):

contesti di Entity Framework sono destinati ad essere utilizzati come istanze di breve durata al fine di fornire l'esperienza più prestazioni ottimali. I contesti dovrebbero essere di breve durata e scartati, e come tali sono stati implementati per essere molto leggeri e per riutilizzare i metadati quando possibile. Negli scenari web è importante tenerlo a mente e non avere un contesto per più della durata di una singola richiesta. Analogamente, in scenari non Web, il contesto deve essere scartato in base alla comprensione dei diversi livelli di memorizzazione nella cache in Entity Framework. In generale, si dovrebbe evitare di avere un'istanza di contesto per tutta la durata dell'applicazione, nonché i contesti per thread e contesti statici.

+0

grazie per il collegamento. molto utile! – Phil

1

È possibile utilizzare l'iniezione, come tramite Unity, che consente di creare una singola istanza di DbContext quando la richiesta arriva e di iniettare quella dove è necessaria. Con Unity, credo che sia possibile specificare se una singola istanza viene creata per richiesta o se una nuova viene creata ogni volta.

Non è molto lento creare DbContext ovunque sia necessario, ma questo ha un po 'di buon senso, quindi riutilizzare quello che già possiedi e se ti concentri sulle prestazioni in relazione alle query del database allora sarà sempre un overhead per l'utilizzo di qualsiasi ORM. È un compromesso di convenienza.

Suggerisco inoltre di utilizzare qualcosa come Glimpse che consente di visualizzare tutte le query e le connessioni utilizzate durante il rendering della pagina, incluse le query ajax e offre una panoramica generale di ciò che sta accadendo. Può essere un po 'spaventoso a volte!