My question is similar to this one on Stack Overflow: What is the correct way to use Unit of Work/Repositories within the business layer?
Scenario:
- .Net solution
- IRepository used to retrieve objects from DB
- IUnitOfWork used to allow transactions across multiple repositories
This makes sense to me and I have implemented something along these lines that works fine. Now I want to introduce a business logic layer and am having trouble organising the three elements (BLL, UnitOfWork and Repository) in my mind.
My understanding:
- Repository - data retrieval, manipulation
- UnitOfWork - persistence
- BLL - logic relevant to the business ('real world') (dislike that term!)
Consider we have an ASP.Net MVC front end.
What does a BLL look like and what does the MVC controller that uses it look like?
For reference: I wonder if perhaps my IUnitOfWork/IRepository implementation might be the underlying cause of my confusion.
public class IRepository<T>
{
private IObjectSet<T> objSet;
public IRepository<T>(IUnitOfWork uow)
{
objSet = uow.CreateObjectSet<T>();
}
public IQueryable<T> Add(T entity)
{
objSet.Add(entity);
}
//etc. etc. for delete, attach, getall
}
So I feel like if I have a BLL, I should be passing it the IUnitOfWork, so that it can use that to create the IRepository instances that it needs. But how will the BLL (separate DLL from the front end) 'know' what implementation of IRepository to build?