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
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:
-
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.
-
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).
-
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
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.