按照http://martinfowler.com/eaaCatalog/unitOfWork.html这篇文章的介绍，UnitOfWork是为了维护对象的变化，A Unit of Work keeps track of everything you do during a business transaction that can affect the database。如果是这样的花，对于ef来说，继承DbContext类都可以看作是unit of work,而dbset<>可以看作是repository, 最终都通过savechanges来完成所有变化的持久化。
如果项目只是用EF，不考虑以后使用其他ORM的可能的话，个人认为没有必要使用unitofwork.对于EF来说本身就实现了这部分功能。
如果考虑今后变化的可能，那需要自己来实现IunitOfWork 和 IRepository 来应对今后的变化，实现对ORM的解耦。
类似的，对于使用的IOC,来说，为了应对未来的变化，也可以有类似的思考，比如有当前使用的autofac，转为使用其他的IOC容器。Common Service Locator就是为了应对这种变化，在IOC容器和Service LOcator 之上抽象的一个类库。实现对IOC容器的解耦