Usually, I consider a large number of parameters as an alarm bell that there may be a design problem somewhere. I am using a Generic Repository for an ASP.NET application and have a Controller with a growing number of parameters.

public class GenericRepository<T> : IRepository<T> where T : class
{
    protected DbContext Context { get; set; }
    protected DbSet<T> DbSet { get; set; }

    public GenericRepository(DbContext context)
    {
        Context = context;
        DbSet = context.Set<T>();
    }
    ...//methods excluded to keep the question readable

}

I am using a DI container to pass in the DbContext to the generic repository. So far, this has met my needs and there are no other concrete implmentations of IRepository<T>. However, I had to create a dashboard which uses data from many Entities. There was also a form containing a couple of dropdown lists. Now using the generic repository this makes the parameter requirments grow quickly.

The Controller will end up being something like

public HomeController(IRepository<EntityOne> entityOneRepository,
                      IRepository<EntityTwo> entityTwoRepository,
                      IRepository<EntityThree> entityThreeRepository,
                      IRepository<EntityFour> entityFourRepository,
                      ILogError logError,
                      ICurrentUser currentUser)
{
}

It has about 6 IRepositories plus a few others to include the required data and the dropdown list options. In my mind this is too many parameters. From a performance point of view, there is only 1 DBContext per request and the DI container will serve the same DbContext to all of the Repositories. From a code standards/readability point of view it's ugly.

Is there a better way to handle this situation? Its a real world project with real world time constraints so I will not dwell on it too long, but from a learning perspective it would be good to see how such situations are handled by others.