I have searched a little bit and I am confused.
First Approach uses a repository and a service for each entity with Autofac. Unit of work class does not have repositories. Therefore, you should create each repository instead of just creating one unit of work class in caller constructor.
OrderService(IUnitOfWork unitOfWork, IUserRepository userRepository,IOrderRepository orderRepository,IBalanceRepository balanceRepository)
Second Approach uses just a generic repository. It uses extension classes instead of using one repository for each entity. Unit of work class has generic repositories.Therefore, you can just create a unit of work class on caller class constructor.
In this approach we use one generic class for repositories but we create a repository object for each entity. If this approach is fine how can I implement it with Autofac ?
Third Approach uses one generic repository and one object for generic repository with Autofac. It uses generic methods instead of generic class. But generic repository has unit of work class instead of opposite. Is this anti pattern ?
OrderService(IUnitOfWork unitOfWork,IGenericRepository repository)
Which approach should I use ?
Best How To :
The sense of the unit of work and the repository pattern is to describe exactly what is needed for example for a use case. So the unit of work which has repositories for every entity or can create a repository for any entity by a generic method is as much to avoid, as a repository that returns an IQueryable. The last flaw will move your Dal to your domain model or even UI (imagine where the filter logic is written and exactly when the filter is executed and where any exceptions will be thrown), the first creates a kind of monolytic application and makes it hard to write unit tests. A unit of work (interface) that only has the 3 Repositories your use case needs and the three repository (interfaces) that have only the methods needed, returning either a single object or a list of objects is more easy to mock and test and specifies exactly what the use case needs and communicates it to your fellow developers (or yourself in 2 years). The interfaces could be implemented (if you choose to) by one big unit of work class and perhaps a few standard repository classes, but thats a different decision that should be guided by the technology (EF code first in earlier versions was not able to have multiple contexts in one database) and the complexity of your application.