我正在处理我的第一个真正的 ASP.NET MVC 项目，我注意到我一直在使用的控制器变得相当大。这似乎违背了保持控制器纤薄的最佳实践。
我做得很好，将业务逻辑排除在控制器之外。我为此使用了一个单独的图层。每个动作主要调用业务层中的一个方法，并根据模型状态是否有效来协调最终结果。
也就是说，控制器有大量的动作方法。直观地说，我想将控制器分解为子控制器，但我没有看到一个简单的方法来做到这一点。我可以简单地将控制器分解为单独的控制器，但我松散了层次结构，感觉有点脏。
有必要重构一个包含大量瘦动作的控制器吗？如果是这样，最好的方法是什么？
首先，当您听说将控制器代码保持在最低限度时很好，这主要是指使每个操作方法尽可能精简（将逻辑改为业务类，而不是视图和视图模型。）看来您正在这样做，这很棒。
至于有“太多”的动作方法，这是一个判断调用。这实际上可能是良好组织的标志，即您让每个行动都专注于一件事。另外，也许您正在使用专门用于 RenderAction 的操作？而且，可能只是您的解决方案的性质，有很多与您的控制器主题相关的事情要做。
所以，我的猜测是你可能很好。然而，为了确保，在便条纸上将控制器分成 2 或 3 个控制器，并勾勒出你的故事将如何从一个动作转移到另一个动作。如果您发现您的工作流程适用于更多控制器，您应该将其拆分。特别是如果您稍后要添加此功能。你越早打破它越好。
好问题。
我相信“薄”控制器可能仍需要“宽”或“高”，具体取决于您要如何扩展类比。如果没有干净的方法来分解需要做很多事情的控制器，我认为这不是问题，只要每个 Action 都专注于准备 Views/ViewModels 并且代码大小有限。
您拥有的另一个结构选项是为操作的逻辑分组引入部分类。并使用类似 vscommands 的东西将文件组合在一起。
我怀疑任何人都可以想出大量的动作来告诉你什么时候分解东西并引入新的控制器是个好主意，这真的取决于你的领域。
另一种解决方案可以是根据控制器中包含的操作的业务概念来分离控制器，但每个操作的路由都符合 REST 规则。
但是，我认为最好仅在有胖控制器的情况下使用此解决方案，否则，最好根据其输出资源对操作进行分类。