Organizing your Data Access Layer

It sounds like you are trying to model a set of disparate data sources as a single model.

If that is indeed the case, my opinion is that creating a project to make the abstraction is the way to go.

I say that because you are dealing with different TYPES of sources. For example, if you just had two databases you could put a link between them, and abstract that way.

But, you have a data warehouse, a few web services, and Active Directory to deal with. I don't know if there would be one way to consolidate across all of those, and even if there were, it could be messy.

Putting the abstraction in a separate project also ensures that you only have to change ONE place when your entities change. It also ensures that you hide the details of what is going on behind the scenes from your front end. This can be important, particularly when you have to add something else (not if - with that many sources something else will surely come along later).

First, you will run through every entity that you have and ask yourself :

Does it make sense to persist this entity alone?

What I mean here, is that in your object model, some entities are likely contained in others in a master-detail relationship. If your entity is highly dependant on another, do not create a repository for this entity alone because it won't likely be persisted by itself. Instead, you will create a repository for each parent class, and you will make sure that the child entities and other relations are persisted at the same time.

I don't like how they implemented the UnitOfWork pattern in the link you provided. I suggest you to do something more along these lines. You don't have to define one class per repository. The same class can be used for every repository, each having their own instance of the UnitOfWork class for the lifetime of the operation. You can also reuse the same UnitOfWork in different repositories for changes that you want persisted at the same time.