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

The patterns you may be looking for are probably Object Pool, or "Identity Map" by Fowler, in his classic book "Patterns of Enterprise Application Development". Using DBContext as an Identity Map is indeed not recommended.

The arguments in that former article boil - more or less - down to "though DBContext has indeed some internal Identity Map, it is too simple for most real-world applications". The article gives some examples, like missing transparency, no control over freeing certain objects (except all of them at once), and no option to manage no-entity classes.

That does not mean you could not try to use DBContext as an Identity Map either, and maybe you are lucky and it provides everything what version 1.0 of your application requires. However, with a growing application, sooner or later you will probably need more control over the lifespan of the objects in the pool than DBContext provides, and then you will be screwed.

I guess your best bet is probably to implement an Identity Map on your own. When you google for "Identity Map" together with some other keywords "C#", "implement" or "example", I am sure you will find some starting points.