CODEWITHSUNDEEP
c#entity-frameworkmvvmentity-framework-core
Julien Ferraro
Julien Ferraro

Reputation: 401

Good usage of DbContext

I'm creating my first application using EntityFramework. I'm using Entity Framework Core and MVVMLight.

I created a DbContext descendant class. I would like to know when to instanciate this DbContext.

My first thought was to create 1 instance for each View.

Imagine the following scenario :

When the user quit the detail view :

Is this a correct way of doing things ? I've read somewhere that one should have only 1 instance of the DbContext. But in this case every modifications to the detail view are propagated to the list view, even if the detail view was canceled.

Many thanx for listening

Upvotes: 2

Views: 1740

Answers (2)

Sampath
Sampath

Reputation: 65978

Hence you're developing WPF application,you can use a context instance per form.

Here it is from EF Team :

When working with Windows Presentation Foundation (WPF) or Windows Forms, use a context instance per form. This lets you use change-tracking functionality that context provides.

I would like to recommend to use repository pattern with Dependency injection (DI).Then you don't need to worry about the instantiation and dispose of the dbcontext. Those are automatic.

Hence you're using EF core, you can use Autofac as a DI API.

Good Article for you : How to work with DbContext

Another good article where it explains how to implement a decoupled, unit-testable, N tier architecture based on Generic Repository Pattern with Entity Framework, IoC Container and Dependency Injection.Yes, this article is for the MVC. But you can get good knowledge of this pattern using this article.

Generic Repository and Unit of Work Pattern, Entity Framework,Autofac

Upvotes: 6

Wiktor Zychla
Wiktor Zychla

Reputation: 48314

There are tons of articles and SO questions on that, google for "DbContext lifetime desktop application". Also, this MSDN magazine might be helpful, although they discuss the case of nHibernate, rules are exactly the same.

Data Access - Building a Desktop To-Do Application with NHibernate

The recommended practice for desktop applications is to use a session per form, so that each form in the application has its own session. Each form usually represents a distinct piece of work that the user would like to perform, so matching session lifetime to the form lifetime works quite well in practice. The added benefit is that you no longer have a problem with memory leaks, because when you close a form in the application, you also dispose of the session. This would make all the entities that were loaded by the session eligible for reclamation by the garbage collector (GC).

There are additional reasons for preferring a single session per form. You can take advantage of NHibernate’s change tracking, so it will flush all changes to the database when you commit the transaction. It also creates an isolation barrier between the different forms, so you can commit changes to a single entity without worrying about changes to other entities that are shown on other forms.

While this style of managing the session lifetime is described as a session per form, in practice you usually manage the session per presenter.

As for the "1 instance of DbContext", this also is commented there:

A common bad practice with [...] desktop applications is to have a single global session for the entire application.

and reasons are discussed below.

Upvotes: 1

Related Questions