最好在MVC中拥有大型控制器或多个控制器？

我们正在ASP.NET MVC中构建一个相当大的HR应用程序，到目前为止，我们的控制器变得越来越大。例如，我们有一个Employee控制器，并且包括了所有雇员视图（个人信息，雇员扣除额，家属等）。这些视图中的每一个都可能具有多个操作或子视图（例如CRUD）。每个动作都相对较小，但是控制器可能具有数十种功能。

是否有拆分控制器的最佳实践？与其让Employee控制器具有数十个视图，不如为每个子类型（即EmployeePersonalInfoController，EmployeeDeductionController，EmployeeDependentController）配备一个控制器会更好吗？

最后，这甚至有关系吗？

更新说明

我最初关心的是CRUD动作。例如，让我们考虑创建和删除...

EmployeeController中的当前操作：

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

如果控制器拆分：

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

在第一种情况下，我们的约100个屏幕分为8-10个大型控制器。在第二个中，我可能会有约50个控制器。

以我的拙见，如果您要使控制器中的代码保持压缩状态，那么这并不重要。

您的大多数代码都将发生在某个地方的业务层中吗？如果是这种情况，那么您在控制器中真正要做的就是将数据返回到视图。应该的。

不太确定我是否喜欢将控制器分成子类型。虽然您应该保持关注点的分离，但我认为子类型有些过分了。

您可以看一下这篇文章，看看是否有帮助。 相同视图的不同路径

这可能比您建议的子类型方法更好。

部分课程使您可以将类分布在多个文件中。这样，您可以将控制器的相关区域分组到单独的文件中，但它们仍将属于同一控制器。例如

EmployeeDeductionController.cs

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

EmployeeBenefitController.cs

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

我不想有50个控制器。现在我的应用程序中有16个，感觉还可以。如果您有50个控制器，则还将有50个用于查看的顶层文件夹。很难找到您需要使用的视图和控制器。正如其他人提到的，动作通常很短，并且在控制器中包含几个动作也并不坏。

我试图按系统部分设置1个控制器。我通过采用数据库模式并在属于一起的表周围画一条线来定义系统部分。

为什么不将它们分组？

具有类似的结构

employee/payroll/
    employee/payroll/giveraise
    employee/payroll/manage401k

employee/general/
    employee/general/address
    employee/general/emergencycontact

现在，您可以有一个薪资控制员来处理与薪资有关的操作，还有一个通用控制员来处理雇员的常规详细信息。

控制器是作为一种上下文中的动作的容器。即，客户控制器将具有与控制客户有关的动作。这特别适合CRUD。由于这个原因，我将使用较少的大型控制器。就是说，作为应用程序架构师，真正由您决定如何选择最适合您的代码的方式，只是因为以一种方式进行更常见并不意味着您必须这样做。

如果您有大量的代码，我建议您研究一下ASP.NET MVC领域。您可以在Scott Gu的博客中和Steve Sanderson的博客中找到关于它的出色文章。。如果您有太多的控制器，则可能适合您。

重新阅读您的帖子后，我只是想了一下，我怀疑您的示例与您的代码中的复杂程度还差得很远。如果您不确定不确定是否拆分一个更具体的控制器（而不是CRUDDY，因为CRUD非常简单），则可能会有所帮助。

我们一直在使用的另一种方法是拥有ControllerBase，以将横切关注点放在CRUD操作的通用位置。该控制器声明通用操作，并包括特定实体内容的扩展点。没有这样的东西，我们有太多的代码重复。

然后，您继承此控制器并为每个实体创建一个。是的，有很多控制器，但是有这么多的屏幕，我认为这不是主要问题。

大多数动作接受一个复杂的模型，然后我们使用模型绑定器进行游戏，以消除控制器上的混乱情况。您可以在此处看到有关此内容的好帖子。

然后，使用@Odd建议这样的区域是一个好主意，至少要分开视图，因为当您有很多视图时便会一团糟。

希望ASP.NET MVC v2将带给我们一些领域，并将视图封装在不同的程序集中（实际上，现在可以通过扩展VirtualPathProvider类来完成）。

我将围绕用例及其逻辑分组大致组织控制器。例如，如果您有多个管理/ HR型用例，可能对一小部分人可用，请将它们捆绑在一个控制器中。可以围绕特定域模型对象来组织其他控制器，例如自助休假管理，薪水查询等。没有硬性规定，必须在不对单个控制器承担过多责任与重用公共控制器之间取得平衡。内部结构。

还请记住，您的控制器中不应包含核心业务逻辑。它们真正实现了前端行为，而真正的系统规则应该在您的域模型和服务层中。只要将事物大致保持在正确的层中并合理地分离，就可以将单个操作放置在控制器中的方式不会太过错误。