What are alternatives to using IQueryable<T> in Repository Pattern? - entity-framework

Question

I am ASP.NET MVC newbie (but .NET experienced dev) and I am trying to learn how to properly set web application infrastructure.
Repository pattern is what I am copping these days and after reading dozens of blogs/articles/answers in the past few days I am still not sure how to use it the right way. I am learning from the Pro ASP.NET MVC 4 Adam Freeman and here is the code for repository interface based on this book:
public interface IRepository<T>
{
IQueryable<T> FindAll();
IQueryable<T> Find(Expression<Func<T, bool>> predicate);
void Add(T newEntity);
void Remove(T entity);
T FindById(long id);
}
After more research online I realized that many people think that returning IQueryable from repository is bad practice and I can (mostly) understand why. However, I can't seem to find answer on what exactly is the alternative? I know about idea of having a custom repository, for each entity, that has specialized method for each possible query which would basically return IEnumerable and not IQueryable... but this just doesn't seem right to me (it's not elegant solution, too many code writing and possible code redundancy etc...).
What are other alternatives?

Answer 1

You have two alternatives.
Specification pattern
The first one is to use the specification pattern. You create a set of classes which are used to limit the search result.
The wikipedia article is a bit poor since it doesn't show how to write business specifications (i.e. "real" specifications). But you basically use the lower level specs (And/Or etc) inside your business specs.
By doing so you can have simpler repository classes and instead code those specifications.
Specific repositories.
Create a repository for every root aggregate (Order, User etc). Each repository have unique query methods that apply to the specific business requirements.
The user repository could have for instance
IPagedResult<User> FindDisabledUser(int pageNumber, int pageSize);
And the order repository could have
IPagedResult<User> GetOrdersReadyForShipping(DateTime orderAfterThisDate);
I've written a set of data layer articles: http://blog.gauffin.org/tag/data-access/. One of those also explains why it's not a good idea to expose IQueryable<T> in your repositories.

Answer 2

As per my comment underneath the original question, this is how I would implement a repository needing more complex query requirements. I have also included my DbContext object for the Entity Framework.
I like this pattern because it hides the Entity Framework implementation behind the repository ensuring that the Entity Framework is not tightly coupled with your application.
public class PersonRepository: IPersonRepository
{
public List<Person> ReadAll()
{
using (var context = new EfContext())
return context.Persons.ToList();
}
public List<Person> ReadPage(int pageIndex, int itemCount)
{
using (var context = new EfContext())
return context.Persons
.Skip(pageIndex * itemCount)
.Take(itemCount)
.ToList();
}
public List<Person> ReadAllWhoseNamesStartWith(string nameExpression)
{
using (var context = new EfContext())
return context.Persons
.Where(r => r.Name.StartsWith(nameExpression)
.ToList();
}
public List<Person> ReadAllWhoseFavouriteColorIs(string color)
{
using (var context = new EfContext())
return context.Persons
.Where(r => r.FavoriteColor.StartsWith(color)
.ToList();
}
}
public class EfContext: DbContext
{
public EfContext(): base("DefaultConnection")
{
}
public DbSet<Person> Persons { get; set; }
public DbSet<Car> Cars { get; set; }
public DbSet<Car> Houses { get; set; }
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
Database.SetInitializer<EfContext>(null);
base.OnModelCreating(modelBuilder);
}
}