恐怕我会变得懒惰。
我正在开发一个 ruby on rails 应用程序，其中涉及大约 8 个模型，涉及两类用户：医生和患者。大多数逻辑都在模型内部，使我的控制器动作非常简短。此外，它使测试变得相当简单。
我目前设想至少有两个控制器，并且我正在编写的测试使我相信我的大多数面向用户的功能都可以由这两个控制器处理。当然，我可以将其分解为更明智的隔间式测试，用于患者控制器、医生控制器、患者药物控制器、患者实验室结果控制器等。但在我看来，这里唯一的优势是更谨慎的组织。
关于这个问题，除了划分之外，还有什么原因不使用尽可能少的控制器，用大量动作打包它们[缺点]，但保持动作精简[优点]？或者......把它带到一个极端：为什么不使用 MVC，有一堆胖模型，和一个瘦的 [虽然很长] 控制器而不是每个患者控制器/模型/视图 + 测试，医生控制器/模型/ EACH 等的视图+测试？
【问题讨论】：
标签： ruby-on-rails ruby model-view-controller model controller
有组织，因为在单个控制器中制作所有内容都是可能的，因此将更难理解和更改。您无法在编辑器中打开文件并立即找到您要查找的操作，而是向下滚动文件以查找您要查找的内容。
这也导致了上帝对象模式，其中所有事情都发生在一个负责所有事情的单个对象中，并且在项目中工作的每个人都将更改同一个对象，从而导致永恒的合并地狱。
而且，Rails 本身具有框架的 RESTful 特性。 Rails 接受了 RESTful 的理念，这个理念的支柱之一是资源，它们只能轻松地组织在单独的控制器中。如果您尝试在同一个控制器中放置两个不同的资源，您最终可能会遇到疯狂的路由或疯狂的控制器逻辑来找出所代表的模型。
如果您认为您的控制器有很多重复的代码，您可以使用一些元编程魔法或约定将它们干掉，但最好将它们分开，这不仅是为了组织，也是为了简化您自己未来的维护。
【讨论】：
如果有很多常见的控制器逻辑，您可以考虑将其抽象为一个插件或模块，以便在需要时混合使用。或者控制器可以继承自一个通用的基本控制器（就像所有控制器默认继承自 ApplicationController，而不是 ActionController::Base）。
我建议不要拥有一个巨大的控制器；控制器应管理与单一类型资源（或可能最接近的类似资源）相关的一组操作。如果您尝试创建一个 RESTful 设计，这个想法会更加强大，其中每个控制器通常只有基本的七个操作（索引、显示、新建、创建、编辑、更新、销毁）。
因此，如果您想拥有像 /patients/52394802/lab_results 这样的 URL，我认为拥有 LabResultsController 是完全有意义的。如果这些控制器是轻量级的，那就太棒了。我认为他们的存在仍然是合理的。这不应该阻止您尝试使您的代码干燥；相反，我会尝试以不同的方式抽象出通用功能。
【讨论】：
这是一个不可能回答的问题。控制器是关于路由和用户交互以及视图而不是业务逻辑。拥有对链接和视图有意义的尽可能多的控制器和操作！
如果您的业务逻辑都在您的模型中，那么它就足够简单了。控制器中逻辑的主要困难是你不能重用逻辑。
真的没什么好说的了。由您决定在您的应用中做有意义的事情。例如拥有一个搜索控制器来搜索东西，而不是向现有控制器添加搜索操作，实际上只是分离和清晰
【讨论】：