Why use a separate class for implementing Unit of Work?

Jan 17, 2011 at 4:01 PM

Just wondering what the reasoning behind implementing unit of work as a concrete class was, instead of implementing commit as a method of the base repository which could implement IUnitOfWork?

Also could the DataBaseFactory class not be implemented in the constructor of BaseRepository and expose the datacontext via a property to pass into other repository instances with an overloaded constructor? Or does the use of Unity for IoC require a use of wrapper class for the DbContext implementation as their is no IDbContext interface available in EFCodeFirst as far as I can see?

Overall a good tutorial just wish their was some clarification and discussion on the architectural decisions made...

Jan 21, 2011 at 1:01 PM

I don't like to use commit methods in repository class and want to implement Unit Of Work as a separate responsibility. A group of transactions may be use multiple repository classes and want to co-ordinate the transaction using a Unit of Work class.  

Jan 22, 2011 at 5:18 PM
That makes sense, although correct me if im wrong if you pass into the CTor of the repository the database factory (or singleton) then the ef context encapsulates the unit of work so calling the commit the method on the repository as opposed to the unitofwork object acheives the same thing? Thinking about it i guess the unitofwork class would make a more logical place to encapsulate transaction logic, i.e. implement rollback functionality etc. I guess their is no right or wrong way of doing it, im just trying to work out a 'best practice' approach :)