>>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
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.