EF Code First with Repository, UnitOfWork and DbContextFactory

I am about to >explode

• There needs to SOLID approach to architecture

• By now, I understand that Entity Framework DbContext is (entirely or to some extent) implementing Unit of Work and Repository patterns, so I could skip all this ;)

• I am really concerned using EF injected directly into Controller constructors (testability, separation of concerns, etc, etc)

• I am also aware that there is more than one way to implement UoW and Repository patterns.

• I am not worried or wanting to build abstractions that will allow me to "swap" ORM (e.g. swap Entity Framework for NHiberante or such).

My Approach

• Repositories are generic and have a base class that implement much of the standard logic.

• Repositories need DbContext via constructor (which is provided by UnitOfWork)

• UnitOfWork is responsible for managing access to all repositories and insuring context is shared among them.

• UnitOfWork is disposable, Repositories are not...

• In order to "hide" DbContext, UnitOfWork is constructed using IDbContextFactory.

Questions

• This seems to work for me, and the advantage I see is that every Controller just needs UoW injected which is nice.

Some Controllers need 2-3 repositories in addition to domain services so this makes things nice...I think...

• Over time, UoW will grow with repositories (there could be 65+ aggregate roots each having a repo). Any ides on how to better manage this? Should I somehow inject Repositories instead od new()-ing them up in the UnitOfWork? I'd love to be able to create a IoC module (Autofac is my poison) to wire up all repos (somehow)

• Is use of IDbContextFactory an overkill or should I just inject DbContext to constructor of UnitOfWork instead? Right now, my web app has no direct dependency on Entity Framework it only depends n DAL (which in turn depends on EF). On the other hand DbContextFactory new()es up MyAppDbContext and is not handled by IoC

• Does anyone notices any other "code smell" ?

If you are likely to grow to 100+ domain objects, I'm making the assumption you will have a lot of logic.

I wouldn't access the repositories directly via the controllers, I would add a service layer that is retrieved by the controllers via the UnitOfWork.

reason being:

-
Your controller actions are likely to bloat and become unmanageable. As you will have alot of boiler code (e.g. Get, Update, Save).

-
The service layer would make you avoid from breaking the DRY principle because you won't be repeating the typical repository code.

-
You could use the Facade pattern to group common tasks that require multiple repositories
http://en.wikipedia.org/wiki/Facade_pattern

-
Your business logic will be in the Service Layer, allowing them to be reused elsewhere, plus your controllers will be loosely coupled to your business logic

example I've built: https://gist.github.com/3025099

StackExchange Code Review Q#11785, answer score: 23