0

I migrated a lot of stored procedures (we want to get rid of them) and I coded them in LINQ using Entity Framework core and SQL server. First let me explain 2 projets that we have in the Backend solution:

Repository : we use the repository pattern with UnitOfWork for simple operations and of course CRUD.

Manager : We use Manager to store all the more complicated queries we can say the real business logic is there.

So far , it's okay but I only use one instance of my DbContext in both projects so i'm wondering if it's better for us to do something like this in each operation instead. 

using (var context = new DBContext())
    {     
        // Perform data access using the context
    }

My goal is to make sure we don't get performance issue because we use the same context for too long and I don't want to keep track of modifications on data over all operations. Also, let's say we have an operation that contains a lot of modifications if an error/exception is thrown I don't want to keep track of anything I want a complete "rollback". We are working in async btw. First time posting here thanks in advance.

ER.Djadel
  • 1
  • As for the context creation, have a look at this: https://stackoverflow.com/questions/50788272/how-to-instantiate-a-dbcontext-in-ef-core/50788386#50788386 – Stefan Jul 23 '19 at 14:42
  • @Stefan But is it really ok to use it that way because it looks like we are using the same instance the framework gives us all the time if we do it that way – ER.Djadel Jul 23 '19 at 14:54
  • Thats the thing; you can determine the scope and the lifetime of the DB context. I would recommend using the frame works build in IoC where possible. Although, I know, migrating towards it can be tricky if you didn't start out with it. – Stefan Jul 23 '19 at 14:57

0 Answers0