Using Entity Framework along with Dapper

I need guidance on designing data layer for my Web API services. The Web API controllers call the service layer which calls the data layer.

I am planning to use Entity Framework along with Dapper. It might not be a good solution to use both of them together, but I need both. I need EF as it is easier to use and developers in my team are familiar. I need Dapper for performance. So, it will be a mix depending on where the dapper can make significant impact and where we can compromise on being a little late.

When using EF, I wanted to use unit of work with repository for each entity. My repository will be like

public class StudentRepository : IStudentRepository, IDisposable
{
    private SchoolContext context;

    public StudentRepository(SchoolContext context)
    {
        this.context = context;
    }

    public IEnumerable<Student> GetStudents()
    {
        return context.Students.ToList();
    }
}

I took that sample code from http://ift.tt/1u56pfd

So, now I wanted to introduce Dapper.

Approach 1: Initially I thought of having multiple repositories for Dapper and for Entity Framework and I can register the one which I need in my dependency injection container. But in this case, all the methods from IStudentRepository interface needs to be implemented in both the EF and Dapper concrete repository classes (if I could do this in Dapper completely, then I don't need EF at all).

Approach 2 : Then I thought about a more ugly approach and it is like exposing a property of IDbConnection along with the DbContext property (in this case SchoolContext) in the above StudentRepository class.

So the example would be like

public class StudentRepository : IStudentRepository, IDisposable
{
    private SchoolContext context;
    private IDbConnection Db;

    public StudentRepository(SchoolContext context)
    {
        this.context = context;
        this.db = new SqlConnection(ConfigurationManager.ConnectionStrings["conn"].ConnectionString);
    }

    public IEnumerable<Student> GetStudents()
    {
        return context.Students.ToList();
    }

    public IEnumerable<Student> GetStudentsBasedOnSomeComplexCondition()
    {
        //I can use the db property here and work with dapper in this case.
    }

(The inclusion of the IDbConnection property can be done through an abstract class so as not to repeat the instantiation code of this property and to easily change the connection string in case if needed. I am adding it in the same class for simplicity).

Approach 3 : Now, I thought of separating it further which I again think is an ugly way. Along with StudentRepository which has only EF stuff (like the first example), I will have another concrete class called StudentDapperRepository which inherits from StudentRepository.

All the methods in StudentRepository will be changed to virtual. So, I will be using StudentDapperRepository for my actual data layer and this will have the Dapper implementations where needed and where not needed, it will use the base class StudentRepository methods (which is in EF).

I think all my solutions are ugly and adding more complexity and confusion. So, can I have some light into how I can do this.