locked
EntityFramework Core, Do we have to explicitly dispose the DBContext RRS feed

  • Question

  • User-1256377279 posted

    Hi Everyone,

    I have an Application using EntityFramework Core with Dependency Injection, My query is when we assign <g class="gr_ gr_149 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling" id="149" data-gr-id="149">dbcontext</g> do we have to explicitly call <g class="gr_ gr_202 gr-alert gr_gramm gr_inline_cards gr_run_anim Grammar only-ins replaceWithoutSep" id="202" data-gr-id="202">dispose</g> the DbContext or it will be automatically <g class="gr_ gr_302 gr-alert gr_gramm gr_inline_cards gr_run_anim Grammar only-ins replaceWithoutSep" id="302" data-gr-id="302">disposed</g> by <g class="gr_ gr_310 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling ins-del" id="310" data-gr-id="310">Complier</g>.

    Or is good practice to <g class="gr_ gr_353 gr-alert gr_gramm gr_inline_cards gr_run_anim Grammar only-ins replaceWithoutSep" id="353" data-gr-id="353">dispose</g> as part of Memory leaks.

            private ANGWorksContext _context;
    
            public DeptService(ANGWorksContext context)
            {
                _context = context;
            }
    
    
    
            public List<Dept_View> GetDepts()
            {
               
                //AutoMapper for Multiple Initialiser Generic
                var dept = Mapper.Map<List<Dept_View>>(GetDepartment());
                
                //Individual Mapper
                //var dept = Mapper.Map<List<Dept>, List<Dept_View>>(GetDepartment());
               
                return dept;
            }
           
            public List<Dept> GetDepartment()
            {
                try
                {
                    var dept = from d in _context.Dept select d;
                    return dept.ToList();
                }
                catch (Exception)
                {
    
                    throw;
                }
                finally
                {
                    _context.Dispose();
                }
    

    Thanks

    Shabbir

    Friday, June 29, 2018 1:29 PM

Answers

  • User1120430333 posted

    I have an Application using EntityFramework Core with Dependency Injection, My query is when we assign dbcontext do we have to explicitly call dispose the DbContext or it will be automatically disposed by Complier.

    Garbage Collection would eventually roll around and dispose all objects that have gone out of scope. In either case of you doing it or GC doing it has nothing to do with the compiler.

    The Try/Finally should be used as the Catch/Throw buys you nothing, since the exception has already happened and you are doing nothing in doing a throw.  

    The IoC is controlling the lifetime of the object, and you should abandon the Dispose().

    If you instanced the dbcontext directly in the code that is about to use the context, then I could see you doing the Dispose(), but you are not doing that and the IoC is doing it and controlling object lifetime too.

    And besides, Web applications are stateless. So  you doing a Dispose() is pointless, IMHO. 

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, June 29, 2018 8:31 PM
  • User1168443798 posted

    Hi shabbier,

    I agree with the suggestion from DA924 that there is no need to disposing the ANGWorksContext object

    For EF Core, the ANGWorksContext is registered and controlled by the Service Container. It will be created and disposed by the Service Container.

    You could refer the link below for how service container control the service like EF Core.

    # Dependency injection in ASP.NET Core

    https://docs.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection?view=aspnetcore-2.1#service-lifetimes-and-registration-options

    Best Regards,

    Edward

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, July 2, 2018 5:38 AM
  • User-821857111 posted

    The Entity Framework itself takes care of ensuring that DbContext objects are closed and disposed properly so there is no need to call Close and Dispose, or use using blocks regardless whether you have registered your Context with the DI system.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, July 2, 2018 6:42 AM
  • User-821857111 posted

    And besides, Web applications are stateless. So  you doing a Dispose() is pointless, IMHO. 
    You should always ensure that unmanaged resources are disposed in a web app otherwise you may end up with memory leaks.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, July 2, 2018 6:45 AM

All replies

  • User1120430333 posted

    I have an Application using EntityFramework Core with Dependency Injection, My query is when we assign dbcontext do we have to explicitly call dispose the DbContext or it will be automatically disposed by Complier.

    Garbage Collection would eventually roll around and dispose all objects that have gone out of scope. In either case of you doing it or GC doing it has nothing to do with the compiler.

    The Try/Finally should be used as the Catch/Throw buys you nothing, since the exception has already happened and you are doing nothing in doing a throw.  

    The IoC is controlling the lifetime of the object, and you should abandon the Dispose().

    If you instanced the dbcontext directly in the code that is about to use the context, then I could see you doing the Dispose(), but you are not doing that and the IoC is doing it and controlling object lifetime too.

    And besides, Web applications are stateless. So  you doing a Dispose() is pointless, IMHO. 

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, June 29, 2018 8:31 PM
  • User1168443798 posted

    Hi shabbier,

    I agree with the suggestion from DA924 that there is no need to disposing the ANGWorksContext object

    For EF Core, the ANGWorksContext is registered and controlled by the Service Container. It will be created and disposed by the Service Container.

    You could refer the link below for how service container control the service like EF Core.

    # Dependency injection in ASP.NET Core

    https://docs.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection?view=aspnetcore-2.1#service-lifetimes-and-registration-options

    Best Regards,

    Edward

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, July 2, 2018 5:38 AM
  • User-821857111 posted

    The Entity Framework itself takes care of ensuring that DbContext objects are closed and disposed properly so there is no need to call Close and Dispose, or use using blocks regardless whether you have registered your Context with the DI system.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, July 2, 2018 6:42 AM
  • User-821857111 posted

    And besides, Web applications are stateless. So  you doing a Dispose() is pointless, IMHO. 
    You should always ensure that unmanaged resources are disposed in a web app otherwise you may end up with memory leaks.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, July 2, 2018 6:45 AM
  • User-1256377279 posted

    Great Thank you <g class="gr_ gr_48 gr-alert gr_gramm gr_inline_cards gr_run_anim Punctuation replaceWithoutSep" id="48" data-gr-id="48">Everyone</g> for useful comments

    Monday, July 2, 2018 9:03 AM
  • User1120430333 posted

    DA924

    And besides, Web applications are stateless. So  you doing a Dispose() is pointless, IMHO. 

    You should always ensure that unmanaged resources are disposed in a web app otherwise you may end up with memory leaks.

    It's all managed code here, there is no unmanaged code. And beside,  GC would take care of it. If I wanted to handle the Dispose, then I'll use a 'using' statement.  But on the other hand, I don't use the 'using' on typed clients as it short-circuits out  without doing a Dispose() 

     https://docs.microsoft.com/en-us/dotnet/framework/wcf/samples/avoiding-problems-with-the-using-statement

    Monday, July 2, 2018 11:36 AM