Question

Well, not sure if that’s exactly the right title, but basically I have been having a lot of problems using repositories in MVC applications in such a way that you can substitute one set of repositories, implementing a different data storage technology, for another.

For example, suppose I want to use Entity Framework for my application. However, I also want to have a set of test data implemented in hard-coded Lists. I would like to have a set of interfaces (IUserRepository, IProductRepository, etc. — let’s not talk about a more generic IRepository<T> for now) that both approaches can instantiate. Then, using (say) a Dependency Injection tool such as Ninject or Castle Windsor, I can switch back and forth between the entity framework provider (accessing the actual database) and the test provider (accessing the lists).

In a nutshell, here’s the problem:

— If you are going to use Entity Framework, you want your repositories returning IQueryable<SomeType>.

— If you are going to use hard-coded lists, you do NOT want your repositories returning IQueryable, because it adds hugely to the overhead, and plus, Linq to Entities is significantly different from Linq to Objects, causing many headaches in the code that is common to both providers.

In other words, I have found that the best approach isolates all the EF-dependent code within the repositories, so that the repositories themselves return IEnumerable or IList or some such — then both EF and some other technology can use the same repositories. Thus, all the IQueryable’s would be contained WITHIN the EF repositories. That way, you can use Linq to Entities with the EF repositories, and Linq to Objects with the Test repositories.

Yet this approach puts an enormous amount of the business logic into the repositories, and results in much duplicated code — the logic has to be duplicated in each of the repositories, even if the implementations are somewhat different.

The whole idea of the repositories as this layer that is very thin and just connects to the database is then lost — the repositories are “repositories” of business logic as well as of data store connectivity. You can’t just have Find, Save, Update, etc.

I’ve been unable to resolve this discrepancy between needing to isolate provider-dependent code, and having business logic in a centralized location.

Any ideas? If anyone could point me to an example of an implementation that addresses this concern, I would be most appreciative. (I’ve read a lot, but can’t find anything that specifically talks about these issues.)

UPDATE:

I guess I’m starting to feel that it’s probably not possible to have repositories that can be swapped out for different providers — that if you are going to use Entity Framework, for example, you just have to devote your whole application to Entity Framework. Unit tests? I’m struggling with that. My practice to this point has been to set up a separate repository with hard-coded data and use that for unit testing, as well as to test the application itself before the database is set up. I think I will have to look to a different solution, perhaps some mocking tool.

But then that raises the question of why use repositories, and especially why use repository interfaces. I’m working on this. I think determining the best practice is going to take a bit of research.

Answer 1

What I can say? Welcome to the club …

What you found is problem reached by many developers who followed “repository boom” with EFv4. Yes it is the problem and the problem is really complex. I discussed this several times:

• ASP.NET MVC 3 and Entity Framework code first architecture
• Organizationally, where should I put common queries when using Entity framework

Separate topic is why to use repositories:

• Generic repository, what is the point

Basically your proposed way is a solution but do you really want it? In my opinion the result is not repository but the Data Access Object (DAO) exposing plenty of access methods. Repository definition by Martin Fowler is:

A Repository mediates between the
domain and data mapping layers, acting
like an in-memory domain object
collection. Client objects construct
query specifications declaratively and
submit them to Repository for
satisfaction. Objects can be added to
and removed from the Repository, as
they can from a simple collection of
objects, and the mapping code
encapsulated by the Repository will
carry out the appropriate operations
behind the scenes. Conceptually, a
Repository encapsulates the set of
objects persisted in a data store and
the operations performed over them,
providing a more object-oriented view
of the persistence layer. Repository
also supports the objective of
achieving a clean separation and
one-way dependency between the domain
and data mapping layers.

I believe exposing IQueryable fulfils this 100 times better then creating a public interface similar to repositories from Stored procedures era – one access method per stored procedure (fixed query).

The problem can be summarized by the rule of leaky abstraction. IQueryable is an abstraction of the database query but the features provided by IQueryable are dependent on the provider. Different provider = different feature set.

What is a conclusion? Do you want such architecture because of testing? In such case start using integration tests as proposed in first two linked answers because in my opinion it is the lest painful way. If you go with your proposed approach you should still use integration tests to verify your repositories hiding all EF related logic and queries.