Generic Repository and Leaky Abstraction - entity-framework

Question

I am implementing a repository pattern. My main reasons for this:
To abstract client code away from persistence specifics (Entity Framework)
To support testability
Generic Repository or not?
The issue I have run into is whether I should have a generic repository or not. An IQueryable<T> Query() method would provide the calling code with means to construct specific queries. The issue here is that this is leaky abstraction - Entity Framework specifics are now leaking into my client code.
How would this effect unit testing? Would I still be able to Mock the ICustomerRepository with this implementation?
How would this effect swopping out my persistence layer? Like Azure Storage Tables or NHibernate.
Otherwise I would have to implement very specific query method on ICustomerRepository, such as GetIsActiveByFirstName() and GetIsActiveByDistrict(). I dislike this a lot as my repository classes are going to become jam-packed with different query methods. This system has hundreds of models and so there could be hundreds or even thousands of these methods to write and maintain.

Answer 1

You can have a relatively clean IRepository<T> by sticking to the pattern.
Data Access LAyer
reference to EF and Core project
Has Respository<T> : IRepository<T>
Option has IEFJunk declaration (Only if using multiple repositories)
Reference to Core
Respository is injected with Context (typically during instantiation)
Core
Interfaces that can be "Injected"
IRepository declaration. With no EF data type use.
NO reference to EF
So now code in Core you can refer to an IRepository<t>.
The implementing class can have EF specifics. But this can not be accessed from core!
so you can have IQueryable.
public interface IRepositoryBase<TPoco>{
IQueryable<TPoco> GetListQ(Expression<Func<TPoco, bool>> predicate);
//...
BUt if you decided you wanted to add
//...
// logically exposing IQueryable<T> Include<T>(this IQueryable<T> source, string path) from EF
IQueryable<TPoco> IncludeNAVProp(string navToInclude);
}
Then the Repository implementation
return Context.Set<TPoco>().Include(navToInclude);
requires the underlying provider to be EF. So now mocking is against an actual EF provider.
And unless you are careful, EF specific code. leaks out.
Indeed the interface IRepository that has the CONCEPT "include" can already be considered LEAKY.
Keeping EF specifics out of your Interfaces, is the key to avoiding the leaks.
And you can have 1 IRepository<t> and 1 Respository<t> and support 100s of tables