Well actually, if you think about it, the Controllers should work with the Unit of Work.
Typically in an ASP.NET MVC application, a Controller is assigned a new unit of work when a HTTP Request comes in.
The Controller will then call methods on the service (which calls methods on the Repository), fetching and making changes to the Entity Framework internal graph/memory.
Once the Controller has done what it needs to do, it will perform a "Commit" on the Unit of Work, which results in any changes to the underlying repository being commited to the database.
I assume when you talk about a "Service", you have a intermediary layer between your Controller and Repository, where the Controller only talks to the Service, the Service then talks to the Repository, then back up the app stack.
So your Controller might look like this:
public class ProductsController : Controller
{
private IUnitOfWork _unitOfWork;
private IProductsService _service;
public ProductsController(IUnitOfWork unitOfWork, IProductsService service)
{
// use dependency injection here
_unitOfWork = unitOfWork;
_service = service;
}
[HttpPost]
public ActionResult SubmitOrder(Product p)
{
var existingProduct = _service.FindById(p.ProductId);
UpdateModel(existingProduct);
_unitOfWork.Commit();
}
}
In most EF4 scenarios, the Unit of Work is implemented as a wrapper for the ObjectContext. In other words, the "Commit" method on your Unit of Work would simply perform "SaveChanges" on the ObjectContext.
Therefore, the Unit of Work doesn't really point to either the service or the repository. It simply works with the persistence mechanism that is manages.
