IUnitOfWork in project silk

Jul 20, 2013 at 1:58 PM

I project silk they are using IUnitOfWork in the BaseRepository class. Is that really necessary? The BaseRepository is adjusted to use with EF dbContext so its not an abstraction for the context in order to be able to change context.
If I'm not mistaken they could have used a property "context" of MileageStatsDbContext and gotten the same result.

What's the point of using IUnitOfWork like they do?
Jul 22, 2013 at 7:57 PM
Edited Jul 22, 2013 at 8:02 PM

I believe that maybe the interface was planned to provide an abstraction layer between the data context and the repositories (besides the BaseRepository, no sub repository implementation access the MileageStatsDbContext directly.) Hence, if you need to change the class in charge of the database context you would only need to refactor the BaseRepository class.

However, it doesn't seems that the IUnitOfWork interface provide a deep abstraction level in the application. Especially since the repositories use a Entity Framework DbSet object to work with the database. Hence the repositories are "abstracted" of the MileageStatsBdContext implementation, but not from Entity Framework.

As you said, if such kind of abstraction is not useful in an application, using a Context property in MileageStatsBdContext could be enough.


Damian Cherubini
Sep 17, 2013 at 12:28 PM
They did it so they could use Unity to inject a DBContext into the repositories. DBContext doesn't otherwise implement an interface, although it does have a SaveChanges method already so technically already implements IUnitOfWork. But they really need to DI that reference to the DBContext into the repositories, so they wrote a hack. The whole BaseRepository falls apart if the IUnitOfWork implementation you give it isn't a DbContext.

So in essence, while pretending to be using DI to loosely couple the repositories and the DBContext, they just mask the tight coupling. The worst of both worlds!