4

I have some EF bounded contexts like follows

public class BoundedContext_1 : DbContext
{
    IDbSet<A> As { get; set; }
    IDbSet<B> Bs { get; set; }
}

public class BoundedContext_2 : DbContext
{
    IDbSet<C> Cs { get; set; }
    IDbSet<D> Ds { get; set; }
}

public class BoundedContext_3 : DbContext
{
    IDbSet<D> Ds { get; set; }
    IDbSet<E> Es { get; set; }
    IDbSet<F> Fs { get; set; }
}

I am trying to implement UoW/Repository pattern for my solution.

Now it seems to me that I will end up creating many repositoris (7 in this case) each of which dedicated to a separate IDbSet of a bounded context and therefore having many units of work (3 in this case) having their own repositories - that's a lot of effort and does not seem feasible since my actual model is much more complicated than the example above.

The question is "Am I forced to go that way? should I have a separate UoW for each bounded context with its own repos?" Or there is a way to avoid this and do it in a simpler way?

Thanks in advance

2 Answers 2

1

No, you are not forced to go that way. In fact, you could use your DbContexts and IDbSets just the way they are.

A DbContext is an implementation of the unit of work pattern. Once created, it will aggregate any changes made to its entities, and will commit when instructed.

In a same way, an IDbSet is an implementation of the repository pattern. It serves as an abstract collection of entities (IQueryable), that can be queried and has basic CRUD operations.

Here are a couple of examples:

public class BService
{
    public void DoSomethingToB(Guid bId)
    {
        using (var unitOfWork = new BoundedContext_1())
        {
            var BRepository = unitOfWork.Bs;
            var b = BRepository.Find(bId);
            b.DoSomething();
            unitOfWork.SaveChanges();
        }
    }

    public B AddNewB()
    {
        var newB = new B();
        using (var unitOfWork = new BoundedContext_1())
        {
            var BRepository = unitOfWork.Bs;
            BRepository.Add(newB);
            unitOfWork.SaveChanges();
        }
        return newB;
    }
}

This will most definitely work. Not a single class created.

The question is whether the EF implementation is sufficient. You should check whether your project's requirements call for a layer of abstraction around EF's implementation.

Such reasons could be:

  1. You have some non-generic logic in a repository or a unit of work that you want to unit test. It isn't straightforward to unit test EF, so you could consider calling EF from your own repo/uow and mock it when unit testing.

  2. You want an explicit API for your repositories. e.g. BRepository.AddNewB(newB) instead of BRepository.Add(newB), or bRepo.GetBWithId(bId) instead of bRepo.Find(bId).

  3. You estimate that you will have to replace your DAL one day and support a technology other than EF. I hear this a lot but never seen such replacement in practice. Usually when a project changes its DAL, the new technology is significantly different and the API is changed together with the implementation (e.g. switching from a RDBS to a NoSQL DB).

3
  • 1- I want to have an explicit API like you said for future extensibility, and 2- I do not want to let the business layer perform queries against the database, because as you already know, if I pass a Linq expression from my business layer to the DAL (EF), it will hit the database, and that's a leak.
    – Kamran
    Oct 16, 2014 at 20:56
  • 2
    Sorry, I'm not sure I follow. 1 - How does an explicit API allows for future extensibility? Also, if you want a custom API for each repo, how would you get by without creating it? Regarding 2, you could always have a single generic repository (e.g. Repository<TEntity>:IRepository<TEntity>) which would abstract EF's repositories. But that would give you a generic API for all repos, which would contradict 1.
    – moranlf
    Oct 16, 2014 at 21:23
  • I've actually just seen the abstraction around EF work in practice. Program written to use EF on a 2005 Db. Turns out the real live one was on 2000, so EF didn't support it. Having the abstraction layer let the dev swap out the EF for an older tech much faster than if the EF had been allowed to seep into the entire code base.
    – RubberDuck
    Feb 9, 2016 at 8:53
1

The simple answer to your question is that EF is itself an implementation of the UoW/Repository pattern. The fact that you are trying to implement a Uow/Repository pattern as if EF were your data source is a good indication you are thinking about your problem incorrectly.

Or there is a way to avoid this and do it in a simpler way?

Yes. Simply use EF as your UoW/Repo implementation, or scrap EF for an alternative implementation.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.