决定 def 应该属于控制器还是模型（Ruby）答案

【问题标题】：Deciding whether def should belong to controller or model (Ruby)决定 def 应该属于控制器还是模型（Ruby）
【发布时间】：2011-07-13 12:20:24
【问题描述】：

所以这是一个相当愚蠢的问题。我还在编写一个网络蜘蛛并且有很多问题，但我想问的第一个问题是你如何决定一个方法应该属于控制器还是模型。

我不想将我的应用程序带入其中，因为有许多特定的“此代码属于控制器还是模型”问题，而我希望这个问题只是作为一般指导方针。

【问题讨论】：

【解决方案1】：

我总是尽可能使用 Skinny Controller，Fat Models - 所以你问题的答案通常是模型。

【讨论】：

【解决方案2】：

我曾在许多环境中工作过，使用过多种语言，从完全程序化到面向对象但不是 MVC，再到带有胖控制器的 MVC 和带有瘦控制器的 MVC。我只能说我自己的观点，但这些都是我这些年来学到的东西，也是我通过经验和不得不处理我写的一些早期代码的维护后果获得的观点（我们都有过去！）。

我也知道很多人会不同意我在这里写的东西，因为这是我们工作的本质；）

脂肪控制器通常很糟糕。这可能表明您的控制器中有模型逻辑，并且在多个控制器中使用模型的情况下，很可能其中一些逻辑被不必要地复制了。
控制器应该为他们的视图提供尽可能少的信息，并且视图应该能够通过询问一两个核心模型来“获取”他们需要的其他信息（例如，不要担心传入一个模型及其关联作为单独的变量。传入模型并让视图在需要时获取关联。我曾研究过通过 10、20、30 的系统（事实上，不幸的是，大多数系统）变量到视图中,当其中许多可能只需要由视图本身按需加载时.我认为 Rails 通常在鼓励模型拉动方法方面做得很好,但我说的是 MVC (on the web ) 作为一个更广泛的概念。
视图可以使用复杂的逻辑。我从事的一些项目认为，因为视图中的某些内容不仅仅是一个简单的“for each”循环，因此需要将其填充到控制器中。那是错的。然后您的控制器正在执行视图逻辑。视图就是代码……我们不要隐藏这个事实。
关于第（3）点，不要将“模板”与“视图”作为一个整体混淆。模板只是您视图的一部分。

我在这里偏离了主题，但简而言之，大部分您的逻辑可能应该在您的模型中完成。你的模型，嗯，根据数据和数据如何变化来模拟你的应用程序。因此很自然，这是放置大量逻辑的地方。您的控制器仅用于在模型和最终用户之间传输信息（恰好是通过视图）。

说“我同意约翰”的方式很啰嗦，对吧？ ;)

【讨论】：