Question

I have seen many repository pattern implementations. Specifically of 2 types

1. They expose the generic repository which is queryable and expects a lamba expression from service class to get data from database.

2. Write methods to get the data from database based on business requirements and encapsulate the logic (even lambda) of retrieving the data.

Which one is a better approach?

Answer 1

I really prefer the second one.

Even I’ve seen articles from top bloggers on .NET world, queryables, for me, are evil in a repository.

Reasons:

1. A repository is like a collection of objects but stored wherever its implementation has defined.

2. A repository abstracts the way data is mapped to object. Data store could be whatever, but business relies on repository in order to retrieve, add, update or remove domain objects.

3. Any read or write access to the underlying store must be managed by the repository itself – or any other underlying layer -.

Queryable destroys most of these points and/or reasons.

For example, why you would design a GetProductByName, GetProductByCode, if you can do it with LINQ on IQueryable?

And Queryable works bad in n-tier scenarios, since you won’t be having access to the database connection in another tier than the one which returned a deferred set.

I don’t think “queryable” concept and repository should be good for any software design, because it’s telling that repository is useless.

Queryable is like designing a GetAll method. What’s the point of a GetAll in a repository? Repository will be retrieving all domain objects and you’ll be filtering them in business. But… Wait… Repository isn’t supposed to retrieve domain objects with some criteria, is it?

Although I find queryable incompatible with repository, designing and implementing some repository method that accepts a lambda expression or any delegate in order to give some kind of filter or behavior, for me, is fine. This isn’t deferred execution, it’s delegation.