I used to implement my repository classes as you can see below
public Class MyRepository
{
private MyDbContext _context;
public MyRepository(My
Let's assume, you have more than one repository and you need to update 2 records from different repositories. And you need to do it transactional (if one fails - both updates rollbacks):
var repositoryA = GetRepository<ClassA>();
var repositoryB = GetRepository<ClassB>();
repository.Update(entityA);
repository.Update(entityB);
So, if you have own DbContext for each repository (case 2), you need to use TransactionScope to achieve this.
Better way - have one shared DbContext for one operation (for one call, for one unit of work). So, DbContext can manage transaction. EF is quite for that. You can create only one DbContext, make all changes in many repositories, call SaveChanges once, dispose it after all operations and work is done.
Here is example of UnitOfWork pattern implementation.
Your second way can be good for read-only operations.
The 1st code doesn't have relation to the scability problem, the reason it is bad is because he create new context for every repository which is bad, which one of commenters comment but he failed to even reply. In web it was 1 request 1 dbContext, if you plan to use repository pattern then it translate into 1 request > many repository > 1 dbContext. this easy to achieve with IoC, but not necessary. this is how you do it without IoC:
var dbContext = new DBContext();
var repository = new UserRepository(dbContext);
var repository2 = new ProductRepository(dbContext);
// do something with repo
As for disposing or not, I usually dispose it but if the lead itself said this then probably no reason to do it. I just like to dispose if it has IDisposable.
Basically DbContext class is nothing but a wrapper which handles all the database related stuffs like: 1. Create connection 2. Execute Query. Now if we do the above mentioned stuff using normal ado.net then we need to explicitly close the connection properly either by writing the code in using statement or by calling the close() method on connection class object.
Now, as the context class implements the IDisposable inteface internally, it is good practise to write the dbcontext in using statement so that we need not care about closing the connection.
Thanks.
I use the first way (injecting the dbContext) Of course it should be an IMyDbContext and your dependency injection engine is managing the lifecycle of the context so it is only live whilst it is required.
This lets you mock out the context for testing, the second way makes it impossible to examine the entities without a database for the context to use.