Whats controlling dbContext instances in IUnitOfWork

Jul 29, 2013 at 12:49 PM
When Silk are using repositories in handler-classes, repositories take a IUnitOfWork in the constructor witch unity makes sure gets an instance of MileageStatsDbContext injected. But when multiple repositories are used, what is it that controls that the same dbContext is used in all repositories?

What is it that makes it a "unit" of work?

It seems they are missing the point of using UnitOfWork because they are calling this.UnitOfWork.SaveChanges(); in Create, Update and Delete method of the repository classes, in that way it cannot be a "unit" of work only one change at a time.

Does anyone have another point of view, because to me it looks like they are using unitofwork just to make the application more complex, and they like to understand what others dont?
Jul 30, 2013 at 7:43 PM

In MileageStats the configuration for the type mappings used by Unity are set in the unity.config file (or unity.debug.config file depending your launch configuration). In that file you can find the following mapping for the IUnitOfWork interface:
<type type="MileageStats.Data.IUnitOfWork, MileageStats.Data" mapTo="MileageStats.Data.SqlCe.MileageStatsDbContext, MileageStats.Data.SqlCe">
    <lifetime type="perRequest" />
Note the "perRequest" setting. This type (defined also in the unity.config file) sets a UnityHttpContextPerRequestLifetimeManager as the lifetime manager for the MileageStatsDbContext instance. As the name implies, this lifetime manager always provides the same instance of MileageStatsDbContext to any class for the current request. For example, each repository created to handle a request made by the client will receive the same context upon construction.


Damian Cherubini