Does a 'leaky' repository implementation defeat the point of a repository?

Question

I've seen some tutorials and examples of implementing a repository pattern, and I don't quite understand something. My impression was that the whole point of a repository pattern was to hide the underlying data storage implementation from the calling code. Am I wrong in this assumption, in which case, what is the point of a repository pattern?

Assuming repositories are meant to hide the underlying implementation, am I right in thinking that implementations like the following EF implementation are leaking EF implementation details and are therefore incorrect repository implementations?

public interface IRepository<TEntity> where TEntity : class
{
    TEntity Get(int id);
    IEnumerable<TEntity> GetAll();
    IEnumerable<TEntity> Find(Expression<Func<TEntity, bool>> predicate);

    // This method was not in the videos, but I thought it would be useful to add.
    TEntity SingleOrDefault(Expression<Func<TEntity, bool>> predicate);

    void Add(TEntity entity);
    void AddRange(IEnumerable<TEntity> entities);

    void Remove(TEntity entity);
    void RemoveRange(IEnumerable<TEntity> entities);
}

As I see it, this leaks the fact that EF entities are being used to store and retrieve data from the DB as TEntity is passed in and returned to and from methods. I'd have thought you'd need to define POCOs, pass them in to the repo, then map then to TEntitys to be correct. Even more leaky is the Expression<Func<TEntity, bool>> predicate lambda, which not only leaks TEntity again but assumes that the underlying implementation implements EF-style .Where() LINQ queries on datasets. This just seems like it's not decoupled from EF.

Am I misunderstanding the purpose of a repository or are my criticisms valid here?

Answer 1

There is absolutely nothing in that interface that leaks the details of the implementation. Without issues you can implement a concrete class with EF, or Dapper, or even MongoDB or whatever you want.

You would have an argument if that interface had some sort of SaveChanges() method or some other pattern or requirement that was essentially driven by EF and not very relevant to other implementations. As it stands, the interface doesn't really suggest anything.