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