One DbContext per web request why

Question

I have been reading a lot of articles explaining how to set up Entity Framework s DbContext so that only one is created and used per HTTP web request using various DI frameworks   Why is this a good idea in the first place  What advantages do you gain by using this approach  Are there certain situations where this would be a good idea  Are there things that you can do using this technique that you can t do when instantiating DbContexts per repository method call

User · Answer

There are two contradicting recommendations by microsoft and many people use DbContexts in a completely divergent manner    One recommendation is to  Dispose DbContexts as soon as posible  because having a DbContext Alive occupies valuable resources like db connections etc     The other states that One DbContext per request is highly reccomended   Those contradict to each other because if your Request is doing a lot of unrelated to the Db stuff   then your DbContext is kept for no reason   Thus it is waste to keep your DbContext alive while your request is just waiting for random stuff to get done      So many people who follow rule 1 have their DbContexts inside their  Repository pattern  and create a new Instance per Database Query so X DbContext per Request  They just get their data and dispose the context ASAP  This is considered by MANY people an acceptable practice  While this has the benefits of occupying your db resources for the minimum time it clearly  sacrifices all the UnitOfWork and Caching candy EF has to offer   Keeping alive a single multipurpose instance of DbContext maximizes the benefits of Caching but since DbContext is not thread safe and each Web request runs on it s own thread  a DbContext per Request is the longest you can keep it   So EF s team recommendation about using 1 Db Context per request it s clearly based on the fact that in a Web Application a UnitOfWork most likely is going to be within one request and that request has one thread  So one DbContext per request is like the ideal benefit of UnitOfWork and Caching   But in many cases this is not true   I consider Logging a separate UnitOfWork thus having a new DbContext for Post-Request Logging in async threads is completely acceptable   So Finally it turns down that a DbContext s lifetime is restricted to these two parameters  UnitOfWork and Thread

User · Answer

What I like about it is that it aligns the unit-of-work  as the user sees it - i e  a page submit  with the unit-of-work in the ORM sense    Therefore  you can make the entire page submission transactional  which you could not do if you were exposing CRUD methods with each creating a new context

User · Answer

One thing that s not really addressed in the question or the discussion is the fact that DbContext can t cancel changes  You can submit changes  but you can t clear out the change tree  so if you use a per request context you re out of luck if you need to throw changes away for whatever reason   Personally I create instances of DbContext when needed - usually attached to business components that have the ability to recreate the context if required  That way I have control over the process  rather than having a single instance forced onto me  I also don t have to create the DbContext at each controller startup regardless of whether it actually gets used  Then if I still want to have per request instances I can create them in the CTOR  via DI or manually  or create them as needed in each controller method  Personally I usually take the latter approach as to avoid creating DbContext instances when they are not actually needed   It depends from which angle you look at it too  To me the per request instance has never made sense  Does the DbContext really belong into the Http Request  In terms of behavior that s the wrong place  Your business components should be creating your context  not the Http request  Then you can create or throw away your business components as needed and never worry about the lifetime of the context

User · Answer

Another understated reason for not using a singleton DbContext  even in a single threaded single user application  is because of the identity map pattern it uses  It means that every time you retrieve data using query or by id  it will keep the retrieved entity instances in cache  The next time you retrieve the same entity  it will give you the cached instance of the entity  if available  with any modifications you have done in the same session  This is necessary so the SaveChanges method does not end up with multiple different entity instances of the same database record s   otherwise  the context would have to somehow merge the data from all those entity instances   The reason that is a problem is a singleton DbContext can become a time bomb that could eventually cache the whole database   the overhead of  NET objects in memory   There are ways around this behavior by only using Linq queries with the  NoTracking   extension method  Also these days PCs have a lot of RAM  But usually that is not the desired behavior

User · Answer

Another issue to watch out for with Entity Framework specifically is when using a combination of creating new entities  lazy loading  and then using those new entities  from the same context    If you don t use IDbSet Create  vs just new   Lazy loading on that entity doesn t work when its retrieved out of the context it was created in   Example    public class Foo        public string Id  get  set         public string BarId  get  set            lazy loaded relationship to bar      public virtual Bar Bar   get  set       var foo   new Foo        Id    foo id       BarId    some existing bar id       dbContext Set lt Foo gt    Add foo    dbContext SaveChanges         some other code  using the same context  var foo   dbContext Set lt Foo gt    Find  foo id     var barProp   foo Bar SomeBarProp     fails with null reference even though we have BarId set

User · Answer

I m pretty certain it is because the DbContext is not at all thread safe  So sharing the thing is never a good idea

User · Answer

Not a single answer here actually answers the question  The OP did not ask about a singleton per-application DbContext design  he asked about a per- web request design and what potential benefits could exist  I ll reference http   mehdi me ambient-dbcontext-in-ef6  as Mehdi is a fantastic resource   Possible performance gains  Each DbContext instance maintains a first-level cache of all the entities its loads from the database  Whenever you query an entity by its primary key  the DbContext will first attempt to retrieve it from its first-level cache before defaulting to querying it from the database  Depending on your data query pattern  re-using the same DbContext across multiple sequential business transactions may result in a fewer database queries being made thanks to the DbContext first-level cache  It enables lazy-loading  If your services return persistent entities  as opposed to returning view models or other sorts of DTOs  and you d like to take advantage of lazy-loading on those entities  the lifetime of the DbContext instance from which those entities were retrieved must extend beyond the scope of the business transaction  If the service method disposed the DbContext instance it used before returning  any attempt to lazy-load properties on the returned entities would fail  whether or not using lazy-loading is a good idea is a different debate altogether which we won t get into here   In our web application example  lazy-loading would typically be used in controller action methods on entities returned by a separate service layer  In that case  the DbContext instance that was used by the service method to load these entities would need to remain alive for the duration of the web request  or at the very least until the action method has completed    Keep in mind there are cons as well  That link contains many other resources to read on the subject  Just posting this in case someone else stumbles upon this question and doesn t get absorbed in answers that don t actually address the question

User · Answer

I agree with previous opinions  It is good to say  that if you are going to share DbContext in single thread app  you ll need more memory  For example my web application on Azure  one extra small instance  needs another 150 MB of memory and I have about 30 users per hour     Here is real example image  application have been deployed in 12PM

User · Answer

NOTE  This answer talks about the Entity Framework s DbContext  but   it is applicable to any sort of Unit of Work implementation  such as   LINQ to SQL s DataContext  and NHibernate s ISession    Let start by echoing Ian  Having a single DbContext for the whole application is a Bad Idea  The only situation where this makes sense is when you have a single-threaded application and a database that is solely used by that single application instance  The DbContext is not thread-safe and and since the DbContext caches data  it gets stale pretty soon  This will get you in all sorts of trouble when multiple users applications work on that database simultaneously  which is very common of course   But I expect you already know that and just want to know why not to just inject a new instance  i e  with a transient lifestyle  of the DbContext into anyone who needs it   for more information about why a single DbContext -or even on context per thread- is bad  read this answer    Let me start by saying that registering a DbContext as transient could work  but typically you want to have a single instance of such a unit of work within a certain scope  In a web application  it can be practical to define such a scope on the boundaries of a web request  thus a Per Web Request lifestyle  This allows you to let a whole set of objects operate within the same context  In other words  they operate within the same business transaction   If you have no goal of having a set of operations operate inside the same context  in that case the transient lifestyle is fine  but there are a few things to watch    Since every object gets its own instance  every class that changes the state of the system  needs to call  context SaveChanges    otherwise changes would get lost   This can complicate your code  and adds a second responsibility to the code  the responsibility of controlling the context   and is a violation of the Single Responsibility Principle  You need to make sure that entities  loaded and saved by a DbContext  never leave the scope of such a class  because they can t be used in the context instance of another class  This can complicate your code enormously  because when you need those entities  you need to load them again by id  which could also cause performance problems  Since DbContext implements IDisposable  you probably still want to Dispose all created instances  If you want to do this  you basically have two options  You need to dispose them in the same method right after calling context SaveChanges    but in that case the business logic takes ownership of an object it gets passed on from the outside  The second option is to Dispose all created instances on the boundary of the Http Request  but in that case you still need some sort of scoping to let the container know when those instances need to be Disposed    Another option is to not inject a DbContext at all  Instead  you inject a DbContextFactory that is able to create a new instance  I used to use this approach in the past   This way the business logic controls the context explicitly  If might look like this   public void SomeOperation         using  var context   this contextFactory CreateNew                  var entities   this otherDependency Operate              context   some value             context Entities InsertOnSubmit entities            context SaveChanges              The plus side of this is that you manage the life of the DbContext explicitly and it is easy to set this up  It also allows you to use a single context in a certain scope  which has clear advantages  such as running code in a single business transaction  and being able to pass around entities  since they originate from the same DbContext   The downside is that you will have to pass around the DbContext from method to method  which is termed Method Injection   Note that in a sense this solution is the same as the  scoped  approach  but now the scope is controlled in the application code itself  and is possibly repeated many times   It is the application that is responsible for creating and disposing the unit of work  Since the DbContext is created after the dependency graph is constructed  Constructor Injection is out of the picture and you need to defer to Method Injection when you need to pass on the context from one class to the other   Method Injection isn t that bad  but when the business logic gets more complex  and more classes get involved  you will have to pass it from method to method and class to class  which can complicate the code a lot  I ve seen this in the past   For a simple application  this approach will do just fine though   Because of the downsides  this factory approach has for bigger systems  another approach can be useful and that is the one where you let the container or the infrastructure code   Composition Root manage the unit of work  This is the style that your question is about   By letting the container and or the infrastructure handle this  your application code is not polluted by having to create   optionally  commit and Dispose a UoW instance  which keeps the business logic simple and clean  just a Single Responsibility   There are some difficulties with this approach  For instance  were do you Commit and Dispose the instance   Disposing a unit of work can be done at the end of the web request  Many people however  incorrectly assume that this is also the place to Commit the unit of work  However  at that point in the application  you simply can t determine for sure that the unit of work should actually be committed  e g  If the business layer code threw an exception that was caught higher up the callstack  you definitely don t want to Commit   The real solution is again to explicitly manage some sort of scope  but this time do it inside the Composition Root  Abstracting all business logic behind the command   handler pattern  you will be able to write a decorator that can be wrapped around each command handler that allows to do this  Example   class TransactionalCommandHandlerDecorator lt TCommand gt        ICommandHandler lt TCommand gt        readonly DbContext context      readonly ICommandHandler lt TCommand gt  decorated       public TransactionCommandHandlerDecorator          DbContext context          ICommandHandler lt TCommand gt  decorated                this context   context          this decorated   decorated             public void Handle TCommand command                this decorated Handle command            context SaveChanges               This ensures that you only need to write this infrastructure code once  Any solid DI container allows you to configure such a decorator to be wrapped around all ICommandHandler lt T gt  implementations in a consistent manner

[c#] One DbContext per web request... why?

Examples related to c#

Examples related to asp.net

Examples related to entity-framework

Examples related to dependency-injection

Examples related to dbcontext