DbContext lifetime in desktop app with SQLite

Question

I am creating a small data-driven desktop application using .NET 5 with WPF, ReactiveUI, Dynamic Data, and EF Core 5. The app uses a local SQLite database to store all persisted state, and relies heavily on dependency injection.

I would like to share state across my app by exposing observables of my EF entities in singleton services, so that when one part of the UI mutates state in the database, the other parts of the UI are notified of changes.

This pattern is really easy to implement if my DbContext is a singleton as well, since all of my entity objects will be shared across the application, change tracking will be automatic, and each singleton service can simply inject the DbContext and use it.

I have read in several places that it isn't recommended to have a a long-living DbContext, even in desktop applications. One article recommended one DbContext per window/dialog.

Without any details on why it's bad practice to have a singleton DbContext in a small desktop app with a local embedded database (other than "it wasn't designed to be used that way"), this just seems like unnecessary complexity. By constantly disposing of the DbContext and creating a new one from scratch, we are creating this disconnect between in memory state and EF's tracked entity state. The short lived DbContext works great in web apps since the request scope is there by default, but desktop apps don't work that way.

I'm perfectly fine with implementing a pattern that limits the scope of the DbContext if it's necessary, but it's unclear how to accomplish this while still keeping app state in sync across the app. I don't want to create a new DbContext for every single operation, but since my view models inject singleton services and don't interact with the DbContext directly, I can't exactly have one DbContext per window.

Could someone please explain in some detail an architecture pattern that would allow for the optimal use of the DbContext while also allowing view models to share state by subscribing to singleton services? Or at least point me to some examples/resources that give actual examples of how to implement this?

Answer 1

Hi mtrainham-9613,
>>Without any details on why it's bad practice to have a singleton DbContext in a small desktop app with a local embedded database (other than "it wasn't designed to be used that way"
First, 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.
And the DbContext class is not thread safe. It is built on the concept of a unit of work, which means you can use it to operate a single use case: therefore for business transactions. It is designed to handle a single request.
Each request creates a new transaction, but tries to use the same transaction DbContext. At this time DbContext detects this error and throws an exception. Because the entity contained in the DbContext is cached locally in your database. It allows you to make a large number of changes and finally commit those changes to the database. When using a single staticDbContext and multiple users call SaveChanges the object, how should I know exactly what should be submitted and what should not be submitted?
For more details I suggest you refer to these links below:
DbContext Lifetime, Configuration, and Initialization
Working with DbContext
One DbContext per web request… why?
.NET Entity Framework and transactions
Best Regards,
Daniel Zhang

---

If the response is helpful, please click "Accept Answer" and upvote it.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.