model-view-controller - 避免在 MVC 中使用大型 Controller

Question

当 Controller 包含大量 Action 时，它们会变得庞大而笨拙。这在实际使用中是否是一个重大问题，如果是，有什么策略可以缓解它(或者足以简单地保持每个 Controller 的 Action 计数)？

在我的脑海中，我可以设想 Controller 将逻辑卸载到其他类型的 Action 实现，根据一些有意义的启发式进行分组。

Answer 1

根据我的经验，这主要发生在我没有足够积极地应用“REST”刀时。有时比喻与我们思考问题的方式不一致；例如，很容易认为“登录”是对“帐户”的操作，但是如果您应用 REST 刀，您就会意识到登录实际上是“开始一个新 session ”，并且您通过应用“新 session ”来颠倒这个想法"(或创建)对 SessionController 的操作。然后你有一个小 Controller 负责创建和销毁 session (登录和注销)。

我相信有些人不会喜欢用困惑的身份验证概念来混淆 REST 的水域，所以让我们看一个更明显的例子。我可以有一个 BlogPost 实体，它可以有一堆评论。我没有在 BlogPostController 上使用 AddComment 操作，而是在 BlogPost 上使用通常的创建/编辑/删除方法，以及另一个 Controller CommentController，其新建/创建操作需要一个 BlogPostId，并实现创建/编辑/删除方法。

我遇到过一些需要非 REST 类操作的情况，例如“从 CSV 文件导入 X 的列表”，其中每个都属于一个 Y； “列表”作为域概念并不是很重要，因为我实际上只是想添加到现有的 Xes 集合中。在那种情况下，我采用了一种我认为有点丑陋的方法，将“导入”操作添加到我的 XController 中。该代码是我的任何 Controller 中最困惑的代码，我倾向于将其分解为包含更多责任的内容(也许是 XImporter 类)，但现在它“有效”。我相信比我更聪明的人会有更好的解决方案。

所以我的论点是:如果你有很多非 RESTy 的 Action ，就会有一种代码异味；也许您没有正确建模您正在控制的内容。但是，如果您说 1-3 次不稳定的操作并尝试重新思考问题并没有将您引向正确的方向，那么也许不值得担心。