Is it OK to create an Entity Framework DataContext object and dispose it in a using block in each of my CRUD methods?

Question

I'm building a wpf application which implements the following features:

1. Take user input and read data from databases
2. perform some calculations on it
3. Showcase it to the user in multiple types of views and write changes back to db

Proposed architecture: Database -> Entity Framework -> Repository -> Business Logic -> Data Service -> ViewModel

Reasons to use this architecture: Multiple scenarios present in the application (Multiple views) and multiple databases. Hence, i'm willing to use repository in the middle for abstraction.

One caveat is that the context will be long lived if repository is implemented. To overcome this, is it okay to create a context and dispose them in a using() block in each of the crud methods.?

feel free to suggest alternate approaches.

Answer 1

Use one DbContext object per data access or transaction.

DbContext is a lightweight object; it is designed to be used once per business transaction. Making your DbContext a Singleton and reusing it throughout the application can cause other problems, like concurrency and memory leak issues.

DbContext essentially implements a Unit of Work. Treat it accordingly.

Don't dispose DbContext objects.

Although the DbContext implements IDisposable, you shouldn't manually dispose it, nor should you wrap it in a using statement. DbContext manages its own lifetime; when your data access request is completed, DbContext will automatically close the database connection for you.

To understand why this is the case, consider what happens when you run a Linq statement on an entity collection from a DbContext. If you return a lazy-loading IQueryable from your data access method, you stand up a pipeline that isn't actually executed until the client compels some data from it (by calling FirstOrDefault(), ToList() or iterating over it).

Further Reading
Do I always have to call Dispose() on my DbContext objects?
Why you shouldn't use Singleton DataContexts in Entity Framework
Returning IEnumerable<T> vs. IQueryable<T>
Should Repositories return IQueryable?

Answer 2

You probably don't need to, but that doesnt mean you should never.

There is a lot of advice, around the internet, and in the top rated post on this page, telling you that you "Must Not" dispose the DB Context.

The logic here is fundamentally flawed. This is a bold statement, so let me explain.

There is a difference between "You don't need to do X" and "You must never do X".

If you create the context, then let the garbage collector take care of it at some undefined time in the future, you aren't going to get memory leaks. This means, essentially, that you "Don't need" to dispose of the context explicitly.

However, this does not logically translate into "Must Never".

If you read the actual MSDN documentation for DbContext you will see that there is a benefit to explicitly disposing the context; it has many resources that it holds, including caches.

Use using if you want all the resources that the context controls to be disposed at the end of the block. When you use using, the compiler automatically creates a try/finally block and calls dispose in the finally block.

If the context is created in application code, remember to dispose of the context when it is no longer required.

https://docs.microsoft.com/en-us/ef/ef6/fundamentals/working-with-dbcontext#lifetime

Leaving the task of disposing that stuff to the garbage collector will slightly increase memory usage - of course, you "Might Not" ever encounter that problem, and will be able to ignore it.

The automatic internal disposal seems to be a safety measure only

Applications doing huge volumes of DB access using a DbContext will have interesting memory usage patterns. Having an understanding of the various modes of garbage collection is important here.

In particular, you need to understand what happens when you hit what Microsoft refer to as "High Memory Usage Percent".

when the physical memory load reaches 90%, garbage collection becomes more aggressive about doing full, compacting garbage collections to avoid paging

This is when the large amount of cached data that you find in as yet undisposed DB context begins to be an issue.

https://docs.microsoft.com/en-us/dotnet/core/runtime-config/garbage-collector#high-memory-percent

Many of Microsoft's own examples of EF usage literally tell you to dispose explicitly

For example, here is a microsoft tutorial (for EF5) of the implementation of a repository.

https://docs.microsoft.com/en-us/aspnet/mvc/overview/older-versions/getting-started-with-ef-5-using-mvc-4/implementing-the-repository-and-unit-of-work-patterns-in-an-asp-net-mvc-application#creating-the-unit-of-work-class

The code sample here explicitly disposes the context when the repo is disposed.

Make a decision based on the facts

The DbContext is intended to act as a single "unit of work". Its unfortunate that Microsoft chose to hide the fact that they are implementing the unit of work pattern - I believe that's what has led to this confusion.

If your services are doing things like, processing huge volumes of data, you will find that the undisposed resources maintained internally by your DbContext will push you into "high memory percentage" territory. At that point, its worth seeing if explicitly disposing of your DbContext makes a difference. You as the developer know that those resources are no longer needed, whereas the garbage collector does not. That isn't its fault - its a general purpose tool.

Answer 3

Ideally the context should be initialized and terminated for a single transaction. In your case the context should be instantiated in Business Logic and passed on to Repository for data read/write.

Answer 4

If you call DbContext on each method in your application you will experience memory leak. Use a single instance of the DbContext. See the comment in the bellow example:

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;
}