asp.net-mvc 在 MVC 中拥有巨大的控制器或许多控制器更好吗？

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

提问by Beep beep

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.

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

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)?

是否有拆分控制器的最佳实践？与其拥有一个拥有数十个视图的 Employee 控制器，还不如为每个子类型（即 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 ...

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

Current Actions in EmployeeController:

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.

在第一个场景中，我们的大约 100 个屏幕被分成 8-10 个大控制器。在第二个中，我可能有大约 50 个控制器。

采纳答案by griegs

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.

这可能是比使用您建议的子类型方法更好的解决方案。

回答by Sam Wessel

Partial classesallow 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

EmployeeDeductionController.cs

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

EmployeeBenefitController.cs

员工福利控制器.cs

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

回答by Mathias F

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.

我不想有 50 个控制器。现在我的申请中有 16 个，感觉还可以。如果您有 50 个控制器，您还将有 50 个用于视图的顶级文件夹。很难找到您需要处理的视图和控制器。正如其他人提到的那样，动作通常很短，在控制器中包含几个动作也不错。

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.

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

回答by SolutionYogi

Why not group them?

为什么不把它们分组？

Have a structure like,

有这样的结构，

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

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

Now you can have one payroll controller handling payroll related actions and a general controller which handles regular details of an employee.

现在，您可以让一个工资控制器处理与工资相关的操作，以及一个处理员工常规详细信息的通用控制器。

回答by Odd

Controllers are meant to be containers for actions under one context. I.E. a customer controller would have actions pertaining to controlling customers. This is particularly suited to CRUD. I would go with fewer larger controllers for this reason. That said, it is really up to you as the application architect to choose the way that best suits your code and just because it is more common to do it one way doesn't mean you have to.

控制器旨在成为一种上下文下操作的容器。即客户控制器将具有与控制客户有关的操作。这尤其适用于 CRUD。出于这个原因，我会使用更少的大型控制器。也就是说，作为应用程序架构师，选择最适合您的代码的方式确实取决于您，并且仅仅因为以一种方式执行此操作更为常见并不意味着您必须这样做。

If you have large amounts of code I would suggest you look into ASP.NET MVC areas. You can find excellent posts about it Here in Scott Gu's blogand Here in Steve Sanderson's blog. If you have so many controllers, it might be suitable for you.

如果您有大量代码，我建议您查看 ASP.NET MVC 领域。你可以在 Scott Gu 的博客和Steve Sanderson 的博客中找到关于它的优秀帖子。如果你有这么多控制器，它可能适合你。

Just had a thought after re-reading your post, I suspect your example doesn't come close to the level of complication you have in your code. Perhaps it might help if you posted a situation where you were unsure whether or not it was a good idea to split your controller that is more specific (and less CRUDDY, because CRUD is fairly straight forward).

重新阅读您的帖子后有一个想法，我怀疑您的示例与代码中的复杂程度不符。如果您发布了一个不确定将控制器拆分为更具体的（而不是 CRUDDY，因为 CRUD 相当简单）是否是个好主意的情况，这可能会有所帮助。

回答by Marc Climent

Another approach we've been using is having a ControllerBase to keep cross-cutting concerns in a common place for CRUD operations. This controller declares the common operations and includes extension points for the specific entity stuff. We had too many code duplication without something like this.

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

Then, you inherit this controller and create one per entity. And yes, there are many controllers but having so many screens, I don't think it will be the main problem.

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

Most of the actions accept a complex Model and we play then with the model binders to remove clutter from the controllers. You can see a good post about that here.

大多数动作接受一个复杂的模型，然后我们使用模型绑定器来消除控制器中的混乱。你可以在这里看到一篇关于这个的好帖子。

Then, using areas like @Odd suggests is a good idea, at least to separate the views because when you have a lot of them is a mess.

然后，使用像@Odd 建议的区域是一个好主意，至少可以将视图分开，因为当你有很多视图时会一团糟。

Hopefully ASP.NET MVC v2 will bring us areas and encapsulating views in different assemblies (actually that can be done now extending the VirtualPathProvider class).

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

回答by Pavel

I would organize the controllers roughly around the use cases and their logical grouping. E.g. if you have multiple administrative/HR-type use cases which are likely to be available to a limited group of people, bundle those in one controller. Other controllers could be organized around specific domain model objects - e.g. self-service leave management, salary queries etc. There's no hard and fast rule, you have to create a balance between not putting too much responsibility into a single controller vs. reuse of common internal structures.

我会大致围绕用例及其逻辑分组来组织控制器。例如，如果您有多个管理/人力资源类型的用例，这些用例可能可供有限的一组人使用，请将它们捆绑在一个控制器中。其他控制器可以围绕特定的域模型对象组织 - 例如自助休假管理、工资查询等。没有硬性规定，您必须在不将太多责任放入单个控制器与重用公共控制器之间建立平衡内部结构。

Remember also that as much as possible you shouldn't have core business logic in your controllers. They really implement the front-end behavior while the real system rules should be in your domain model and service layer. As long as you keep things roughly within the right layer and reasonably decoupled, you can't go too far wrong with how you place the individual operations within your controllers.

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