Question

Ayende wrote sometime ago a set of articles about how Repositories are the new Singletons pattern. I've read them all, I think and I was agree in several of his points. Most of the times I see projects with tens of repositories which are there just to abstract the usage of one ORM, which already abstracts the database access.

After avoid them, I started having some problems to isolate my code for UT because some ORMs are hard-to-mock software pieces, or at least EF is. Some of the Ayende's projects are tested using an in-memory database but, even when it works okay, I don´t want to do so.

So, this is my problem: I don´t like to have tens of the typical repositories nor generic repository neither however, I want to have an easy way to isolate my code.

Are currently Repositories only useful for UTs?

Note: I am talking about database access, not about abstracting other kind of data sources like remote service.

Was it helpful?

Solution

To me, repositories (or DAOs) are useful because they isolate persistence-related code from business-logic code.

One of the (desired) side effects is that both the business logic code and the data access code become much easier to test.

Another desired side-effect is that the persistence-related methods are easily resusable by multiple business-logic services.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top