0

Is it a bad practice to expose DbContext in your service layer?

For Example:

private readonly IRepository<SkillLevels> _repository;
private readonly IDatabaseFactory _databaseFactory;
private readonly IUnitOfWork _unitOfWork;

public SkillLevelService(IRepository<SkillLevels> repository, IDatabaseFactory databaseFactory, IUnitOfWork unitOfWork)
{
    _repository = repository;
    _databaseFactory = databaseFactory;
    _unitOfWork = unitOfWork;
}

public void InsertSkillLevel(SkillLevels entity)
{
    _repository.Insert(entity);
    _unitOfWork.Commit();
}

Here, IDatabaseFactory can return my DbContext object. I exposed it here because if i need other entities other than SkillLevels, so that i can use them in this service class. In case you know, for complex queries when you need to select multiple tables to fetch data.

But i'm not sure if it makes a bad practice!!

Any help is appreciated. Thanks.

Milan Solanki
  • 1,207
  • 4
  • 25
  • 48
Md Nazmoon Noor
  • 3,187
  • 1
  • 24
  • 30

2 Answers2

0

One issue I see is you are using a generic repository. It can work for simple cases but as you said if you need to do joins this approach is not going to work. So one improvement would be to create specific repos

public interface ISkillLevelsRepository : IRepository<SkillLevels>
{
  //have specific methods to achieve what you want
}

Another approach would be to use multiple repositories inside your service class and remove the Factory.

private readonly IRepository<SkillLevels> _skillsRepository;
private readonly IRepository<Student> _studentRepository;
private readonly IUnitOfWork _unitOfWork;

public SkillLevelService(IRepository<SkillLevels> skillsRepository, IRepository<Student> studentRepository, IUnitOfWork unitOfWork)
{
    _skillsRepository= skillsRepository;
    _studentRepository = studentRepository;
    _unitOfWork = unitOfWork;
}

Then access multiple repos to achieve what you need.

One more thing if you have defined your model correctly with all navigational fields you may rarely need to do joins because EF will add the joins when you refer the navigational properties.

Eranga
  • 32,181
  • 5
  • 97
  • 96
  • Thanks. I knew about both approaches you mentioned. But personally i don't like the second approach, cause truth to be told, i like using the Context object. I feel safe with it.:D Second, for now this service may workaround with these 2 repositories. But in future this service may need more repositories. then i'll have to add them on constructor again. – Md Nazmoon Noor Aug 07 '11 at 11:20
  • About your first appraoch i like it better. Do you know any open source sample app than that can help me understand this better. – Md Nazmoon Noor Aug 07 '11 at 11:38
  • @Nazmoon sorry i can't recall any samples. but the structure would depend on your domain – Eranga Aug 07 '11 at 14:03
0

It is quite common in a web application to just use a single DBContext per request and create it on BeginRequest then pass it to all the calls in the request and dispose it on EndRequest.

See this example One DbContext per request in ASP.NET MVC (without IOC container)

Community
  • 1
  • 1
lahsrah
  • 9,013
  • 5
  • 37
  • 67