Hi,
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 FrameworkDbSet 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.
Regards,
Damian Cherubini
http://blogs.southworks.net/dcherubini
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 FrameworkDbSet 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.
Regards,
Damian Cherubini
http://blogs.southworks.net/dcherubini