判断def是否属于控制器或模型（Ruby）

Question

所以这是一个相当无聊的问题。我仍在编写网络蜘蛛编码并且有很多问题，但我要问的第一个问题是你如何确定方法是属于控制器还是模型。

我不想把我的应用程序带到这里，因为有许多特定的“这个代码属于控制器或模型”这些问题，而我希望这个问题只是作为一般指导。

Answer 1

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

Answer 2

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

我也知道很多人会不同意我在这里所写的内容，因为这就是我们工作的本质;）

1. 脂肪控制器通常很糟糕。它可能表明你的控制器中有模型逻辑，并且模型在多个控制器中使用，很可能会有一些逻辑被不必要地复制。
2. 控制器应该根据需要向他们的视图提供尽可能少的信息，并且视图应该能够“拉入”他们需要的其他内容，通过询问一个或两个核心模型（例如，不要担心传入模型及其关联作为单独的变量。传入模型并让视图在需要时获取关联。我已经研究了系统（实际上，我会说，不幸的是，大多数系统）通过了10年代，20年代，30年代的将变量放入视图中，其中许多可能只需要由视图本身按需加载。我认为Rails通常可以很好地鼓励模型拉取方法，但我在谈论MVC（在网络上） ）作为一个更广泛的概念。
3. 视图可以使用复杂的逻辑。我曾经研究过的一些项目认为，因为视图中的某些东西不仅仅是一个简单的“for each”循环，所以它需要填充到控制器中。那是错的。然后，您的控制器将执行视图逻辑。视图是代码......让我们不要隐瞒这个事实。
4. 关于第（3）点，不要将“模板”与“视图”混淆为一个整体。模板只是您视图的一部分。

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

说“我同意约翰”是一种啰嗦的方式，是吗？ ;）