Using a lengthy context is acceptable as long as you are aware of the consequences.
A context stands for a piece of work. All pending modifications to the tracked entities are saved to the database each time SaveChanges is called. You must therefore limit each situation to what makes sense. For instance, if you have a tab for managing customers and another for managing items, you might utilize one context for each to prevent all changes made to products when a user clicks save on the customer tab from also being saved.
DetectChanges may take longer if a context is tracking a large number of entities. Using change tracking proxies is one strategy for reducing this.
There is a higher likelihood of running into an optimistic concurrency error when loading an entity and saving it than when using short-lived contexts because of the potential length of time between those two actions. When an object is altered externally between being loaded and being saved, certain exceptions take place. Although Taking care of these exceptions is quite simple, it is nevertheless important to be aware of.
Binding to the DbSet is one amazing thing you can do with WPF with long-lived contexts. Local property (for instance, context. Customers.Local). Those tracked entities that have not been designated for deletion are collected in this ObservableCollection.
Hopefully, this has provided you with a little more knowledge to aid in your decision of how to assist.