Domanda
Nell'applicazione Windows Form, all'avvio del modulo, carica i dati dal database. Passa innanzitutto al livello Dati persistenza e crea nuovo DBContext.
public DataEntities DBContext = new DataEntities();
Dopo questo carica i dati.
Dispongo DBContext sull'evento close form. Il motivo è che utilizzo la proprietà Local di DBContext per interrogare i dati. Quindi interroga i dati della memoria dopo il caricamento e non il database che è buono (veloce). L'altra cosa è che solo l'utente che avvia il programma ha accesso ai propri dati (e non ai dati di altri utenti). Quindi c'è pochissima possibilità che qualcuno possa modificare i suoi dati (solo il suo vice).
Quindi, DBContext non viene eliminato finché il modulo non viene chiuso.
Nota 1: questo è il modulo per l'inserimento dei dati. Non è la forma principale. Sul modulo principale lo smaltirò immidiatamente poiché la forma principale è solo per visualizzare i dati.
Nota 2: l'applicazione verrà utilizzata nella rete locale e il numero di utenti è intorno a 40.
Nota 3: utilizzo il framework di entità 6.1.3
Dopo aver caricato i dati all'avvio, in sql profiler ho notato che il comando sql è chiamato:
exec sp_reset_connection
La mia domanda è: Posso usare questo approccio e disporre DBContext quando il modulo si chiude (sull'evento di chiusura del modulo)?
Risposta accettata
Sicuro. Questo è noto come scenario connesso , ovvero il contesto rimane "connesso" (attenzione alle virgolette) al database e si salvano le stesse entità prese dal database.
In un'applicazione rich client come un'applicazione Windows Form questo è un modello comune per finestre di dialogo di modifica relativamente di breve durata. Ed è esattamente quello che stai facendo qui.
Il contesto in realtà non mantiene una connessione aperta al database. Chiude la connessione dopo ogni interazione con il database, quindi la registrazione di Sql Profiler.
Una cosa da considerare. Anche se ci sono poche possibilità che gli utenti modifichino gli stessi dati contemporaneamente, si consiglia di introdurre un controllo ottimistico della concorrenza . EF lo rende relativamente facile.
Risposta popolare
Quando il tuo DbContext ha una lunga durata, ecco alcune considerazioni (entità connesse):
Ogni entità recuperata da SQL Server verrà caricata nella memoria nella cache di primo livello (RAM USAGE).
Se i dati vengono modificati da altri DbContext, potresti ottenere alcuni problemi di concorrenza.
Se il LIVELLO DI ISOLAMENTO DI TRANSAZIONE SQL Server è LEGGI NON CORRETTO, è possibile che si ottenga una lettura non corretta.
Se hai un sacco di entità che vengono caricate nel DbContext (Migliaia), l'applicazione sarà generalmente più lenta e forse avrai problemi di prestazioni quando proverai a cambiare un'entità perché l'EF deve tenerli tutti.
Autorizzato sotto: CC-BY-SA with attribution
Non affiliato con Stack Overflow