Va bene creare un oggetto Entity Framework DataContext e disporlo in un blocco using in ciascuno dei miei metodi CRUD?

Utilizza un oggetto DbContext per accesso ai dati o transazione.

DbContext è un oggetto leggero; è progettato per essere utilizzato una volta per transazione commerciale. Rendere il DbContext un Singleton e riutilizzarlo in tutta l'applicazione può causare altri problemi, come la concorrenza e problemi di perdita di memoria.

DbContext implementa essenzialmente un'unità di lavoro . Tratta di conseguenza.

Non disporre gli oggetti DbContext.

Anche se DbContext implementa IDisposable , non dovresti eliminarlo manualmente, né doverlo racchiudere in un'istruzione using . DbContext gestisce la propria durata; quando la richiesta di accesso ai dati è completata, DbContext chiuderà automaticamente la connessione al database per te.

Per capire perché questo è il caso, considera cosa succede quando si esegue un'istruzione Linq su una raccolta di entità da un DbContext . Se restituisci un pigro caricamento IQueryable dal tuo metodo di accesso ai dati, tieni in piedi una pipeline che non viene effettivamente eseguita finché il client non ne costringe alcuni dati (chiamando FirstOrDefault() , ToList() o iterando su di esso) .

Ulteriori letture
Devo sempre chiamare Dispose () sui miei oggetti DbContext?
Perché non dovresti usare Singleton DataContexts in Entity Framework
Returning IEnumerable<T> vs. IQueryable<T>
I depositi dovrebbero restituire IQueryable ?

Idealmente, il contesto dovrebbe essere inizializzato e terminato per una singola transazione. Nel tuo caso, il contesto dovrebbe essere istanziato in Business Logic e trasmesso al repository per i dati di lettura / scrittura.

Se si chiama DbContext su ciascun metodo dell'applicazione, si verificherà una perdita di memoria. Utilizzare una singola istanza di DbContext. Vedi il commento nell'esempio seguente:

public bool IsInStock(int _ProductId)
{
  var result = false;

  try
  {
    using (var dataService = new StoreDbDataService()) // NB: This line on each method will eventually cause memory leak.
    {
      result = dataService.IsInStock(_ProductId);
    }
  }
  catch (Exception ex)
  {
    Log.LogException(ex);
  }

  return result;
}