Repository pattern for books in EF6
1) I would not expose IQueryable via IRepository. IQueryable is still a virtual set of objects that hasn't been retrieved from a database yet. If you have (for example) some problem with database performance, you would have to go through all your application to find out what queries you construct and send to DB.

Instead I would expose methods for specific purposes on specific repositories. These methods would return IList&lt;T&gt; (or ICollection&lt;T&gt;, depends on your preference). Then you have all the code for accessing a database on a single place. For example, your IBookRepository would look like:

public interface IBookRepository : IRepository&lt;Book&gt;
{
    Book FindByIsbn(string isbn);
    IList&lt;Book&gt; FindByAuthor(int authorId);
    IList&lt;Book&gt; FindByTitle(string title);
    ...
}


And your generic repository would be:

public interface IRepository&lt;T&gt;
{
    T FindById(int id);
    void AddOrUpdate(T entity);
    void Remove(T entity);
}


2) It is not necessary to make your repositories disposable. So far you have nothing to dispose there. Your repositories get IDbContext (which is IDisposable) from outside, thus it should not be disposed inside a repository. If your repositories get created via an IoC container, the container will also handle disposing of all dependencies.

3) UnitOfWork: You can implement UnitOfWork pattern if you want to (e.g.) wrap all your database work inside transactions. I would recommend such IUnitOfWork interface:

public interface IUnitOfWork
{
    void SaveChanges();
    void BeginTransaction();
    void CommitTransaction();
    void RollbackTransaction();
}


Implemetation of IUnitOfWork would have dependency on IDbContext. Then the only places where you work with a database (via IDbContext) are UnitOfWork and Repository classes. At places where you want to save your work to a DB, use IUnitOfWork, not IDbContext.