Last post Apr 17, 2010 11:58 AM by email@example.com
Apr 16, 2010 05:40 AM|danludwig|LINK
According to the ADO.NET Team blog, I'm not supposed to hide UnitOfWork behind my repository. Instead, I'm supposed to
construct the repository using IUnitOfWork. This means the client would need to construct a UnitOfWork context before they could construct the repository.
This is confusing me a little. If I want to dependency inject the repository, and the repository requires a UnitOfWork context of a specific type, how can I inject the IUnitOfWork with the repository? Should the client really need to construct a new context
just for the sake of constructing a new repository? I understand why this is good design practice if you have multiple repositories that use the same IUnitOfWork context. But, if you only have one (small) repository, should you need to create a separate UnitOfWork
implementation for it? Or is it okay to just expose a SaveChanges() or Commit() method directly from the repository?
Apr 17, 2010 11:58 AMfirstname.lastname@example.org|LINK
You could always optionally inject a UnitOfWork instance to repositories if you want to use it using method injection rather than constructor injection, something like:
Then if no unit of work is injected the commit happens as part of the save method.
Otherwise inject it into the Repositories constructor:
public customerRepository(IUnitOfWork uow)