在MVC中最好拥有巨大的控制器或许多控制器？

我们正在ASP.NET MVC中构build一个相当大的HR应用程序，到目前为止，我们的控制器变得相当大。 例如，我们有一个员工控制器，包括所有员工的意见（个人信息，员工扣除，家属等）。 每个视图都可能有多个操作或子视图（例如CRUD）。 每个动作都比较小，但是控制器可能有几十个function。

有没有最佳的做法分裂控制器？ 而不是拥有几十个视图的员工控制器，它会更好，每个子types（即EmployeePersonalInfoController，EmployeeDeductionController，EmployeeDependentController）有一个控制器？

最后，它甚至重要吗？

更新说明

我最初的担心是与CRUD行动。 例如，让我们考虑创build和删除…

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个控制器。

Answer 1

在我看来，如果你把代码保存在你的控制器中，那么它并不重要。

你的大部分代码会在某个业务层上发生吗？ 如果是这样的话，那么你在控制器中所做的一切就是将数据返回给视图。 它应该是。

不太确定我是否是将控制器分成子types的粉丝。 虽然你应该保持分离的担忧，我认为亚型会有点过头。

你可以看看这个post，看看是否有帮助。 同一视图不同的path

这可能比使用你build议的子types方法更好。

Answer 2

部分课程允许您将课程分散到多个文件中。 这样你可以将你的控制器的相关区域分组到不同的文件中，但是它们仍然是同一个控制器的一部分。 例如

EmployeeDeductionController.cs

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

EmployeeBenefitController.cs

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

Answer 3

我不想有50个控制器。 现在我的应用程序有16个，感觉还好。 如果你有50个控制器，你也将有50个顶层文件夹的意见。 将很难find您需要处理的视图和控制器。 正如其他人所说的，动作通常很短，在你的控制器中有一些动作并不坏。

我试图由系统部分有1个控制器。 我通过使用我的数据库模式定义了一个系统部分，并围绕在一起的表格绘制一行。

Answer 4

为什么不把他们分组？

有一个像，

 employee/payroll/ employee/payroll/giveraise employee/payroll/manage401k employee/general/ employee/general/address employee/general/emergencycontact 

现在，您可以有一个薪资控制人员处理薪资相关操作，以及一个处理员工常规细节的总体控制员。

Answer 5

控制器意味着在一个环境下的行动的容器。 IE客户控制器会有控制客户的行为。 这特别适合于CRUD。 出于这个原因，我会select更less的控制器。 也就是说，作为应用程序架构师，select最适合您的代码的方式真的取决于您，仅仅因为这样做更为常见，并不意味着您必须这样做。

如果你有大量的代码，我build议你看看ASP.NET MVC领域。 你可以在这里findScott Gu的博客和Steve Sanderson的博客Here 。 如果你有这么多的控​​制器，它可能适合你。

刚刚重新阅读您的文章后有一个想法，我怀疑你的例子不接近你的代码中的复杂程度。 也许这可能会有帮助，如果你张贴了一个情况，你不能确定是否是一个好主意拆分你的控制器是更具体的（更lessCRUDDY，因为CRUD是相当简单的）。

Answer 6

我将大致围绕用例及其逻辑分组来组织控制器。 例如，如果您有多个行政/人力资源types的用例，这些用例可能会向有限的一群人提供，请将其捆绑在一个控制器中。 其他控制器可以围绕特定的领域模型对象进行组织 – 例如，自助服务休假pipe理，工资查询等等。没有硬性规定，你必须在不把太多的责任放在一个控制器上，内部结构。

请记住，尽可能多的你不应该有你的控制器的核心业务逻辑。 他们真正实现了前端行为，而真正的系统规则应该在你的域模型和服务层。 只要你把事情粗略地放在合适的层次上并合理地解耦，你不能在你的控制器中放置单独的操作时犯太多错误。

Answer 7

我们使用的另一种方法是使用ControllerBase将交叉关注点放在CRUD操作的常见位置。 这个控制器声明通用操作，并包含特定实体的扩展点。 没有这样的东西，我们有太多的代码重复。

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

大部分的行为都接受了一个复杂的模型，然后我们使用模型活页夹去除控制器的混乱。 你可以在这里看到一个好的post。

那么，使用像@Odd这样的区域是一个好主意，至less可以将意见分开，因为当你有很多的时候是一团糟。

希望ASP.NET MVC v2能为我们带来不同程序集的区域和封装视图（实际上现在可以扩展VirtualPathProvider类）。