Repository Pattern - MVC storefront

Question

Have been looking at the MVC storefront and see that IQueryable is returned from the repository classes. Wondering if you are not using LINQ does it makes sense to return that object? In the case of LINQ in makes sense because of deferred execution, so adding filtering in the service layer makes sense, but if you don't use LINQ you would want to filter in the DB in many cases. In this case would I just add methods that do the filtering to the repository? If I do, is the service layer really useful?

Answer 1

Arguments can be made either way, see this recent blog posting: Should my repository expose IQueryable?

Answer 2

The IQueryable stuff that Rob Conery put into the MVC Storefront is innovative, but by no means the norm when it comes to creating repositories. Usually, a repository is responsible for mapping your domain to and from the database. Returning IQueryable doesn't really perform any mapping and relies on the services layer to do that. This has its advantages and disadvantages, but suffice it to say that it's not the only way to do it.

You will notice, however, that your services end up becoming a little smelly because of all the duplicate code. For instance, if you just want to get a list of all the users in your database you'd have to define that function in both the repository and the service layer. Where the service layer shines, however, is when multiple transactions to/from the database are needed for one operation.

Answer 3

The issue I have with exposing IQueryable to the Service Layer is that if you ever wanted to wrap the Repository layer behind a Web Service without breaking the Service Layer code you couldn't, well not without using ADO.NET Data Services but then all your Repository code would essentially become redundant.

Whilst I think it can be pretty productive for small apps, when you start looking at scaling and distribution it does more bad than good.