Better to have huge Controllers, or many controllers, in MVC?

We are building a fairly large HR application in ASP.NET MVC, and so far our controllers are becoming quite large. For example, we have an Employee controller, and all employee views are included (Personal info, employee deductions, dependents, etc). Each of these views might have multiple actions or subviews (e.g. CRUD). Each action is relatively small, but the controllers might have dozens of functions.

Are there any best practices for splitting controllers? Instead of having an Employee controller with dozens of views, would it be better too have one controller for each subtype (i.e. EmployeePersonalInfoController, EmployeeDeductionController, EmployeeDependentController)?

And finally, does it even matter?

Updated Clarification

My original concern was with CRUD actions. For example, let's consider Create and Delete ...

Current Actions in EmployeeController:

  CreateEmployee()
  DeleteEmployee()
  CreateEmployeeDeduction()
  DeleteEmployeeDeduction()
  CreateDependent()
  DeleteDependent()
  etc.

If the controllers were split:

  EmployeeController
    Create()
    Delete()
  EmployeeDeductionController
    Create()
    Delete()
  EmployeeDependentController
    Create()
    Delete()
  EmployeeBenefitController
    Create()
    Delete()
  etc.

In the 1st scenario, our ~100 screens get split into 8-10 large controllers. In the second, I'd probably have ~50 controllers.

Partial classes allow you to spread your class across multiple files. That way you can group relevant areas of your controller into separate files, and yet they'll all still be part of the same controller. e.g.

EmployeeDeductionController.cs

public partial class EmployeeController
{
    public ActionResult Deduct()
    {
    }
    // etc
}

EmployeeBenefitController.cs

public partial class EmployeeController
{
    public ActionResult GiveBenefit()
    {
    }
    // etc
}

In my humble opinion, if you are keeping the code in your controllers down then it doesn't really matter.

Most of your code would be happening in a business layer somewhere right? If that's the case then all you are really doing in your controller is returning data to the view. As it should be.

Not really sure if I'm a fan of seperating the controllers into subtypes. Whilst you should maintain seperation of concerns I think subtypes is going a little too far.

You could take a look at this post to see if it helps. Same View Different Paths

That may be a better solution than using a subtype approach that you suggested.

I would not want to have 50 controllers. Right now I have 16 in my application and that feels ok. If you have 50 controllers you will also have 50 toplevel folders for views. It will be hard to find the view and controller you need to work on. As others mentioned actions are typically short and its not that bad to have a couple of them in your controller.

I tried to have 1 controller by system part. I define a system part by taking my database schema and drawing a line around tables that belong together.