决定 def 应该属于控制器还是模型 (Ruby)

发布于 2024-11-24 01:38:26 字数 136 浏览 0 评论 0原文

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

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

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

濫情▎り 2024-12-01 01:38:26

我总是尽可能选择瘦控制器、胖模型 - 所以你的问题的答案通常是模型。

回复收藏 0 原文

霓裳挽歌倾城醉 2024-12-01 01:38:26

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

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

胖控制器通常都是不好的。这可能表明您的控制器中有模型逻辑，并且在多个控制器中使用模型的情况下，很可能其中一些逻辑被不必要地重复。
控制器应该向其视图提供尽可能少的信息，并且视图应该能够通过询问一两个核心模型来“拉入”他们还需要的信息（例如，不要担心传递模型及其传递模型并让视图在需要时获取关联。我曾在将 10 个、20 个、30 个变量传递到视图，当其中许多可以简单地由视图本身按需加载时，我认为 Rails 通常在鼓励模型拉取方法方面做得很好，但我正在谈论 MVC（在网络上）。视图可以使用复杂的
逻辑，因为视图中的某些内容不仅仅是简单的“foreach”循环，因此需要将其填充到控制器中。那是错误的。视图就是代码……我们不要隐藏这个事实，
关于第 (3) 点，不要将“模板”与“视图”作为一个整体混淆。模板只是您视图的一部分。

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

说“我同意约翰的观点”是相当冗长的方式，不是吗？ ;)

I've worked in many environments, in many languages, ranging from entirely procedural, to object-oriented but not MVC, to MVC with fat controllers and MVC with skinny controllers. I can only speak of my own opinions, but these are things I've learned over the years and opinions I've gained through experience and having to deal with the maintenance consequences of some of the early code I wrote (we all have a past!).

I also know that many people will disagree with what I write here, as that is the nature of how we work ;)

Fat controllers are generally bad. It probably indicates that you have model logic in your controllers and where models are used in more than one controller, there's a good chance some of that logic is being needlessly duplicated.
Controllers should give as little information as needed to their views, and the views should be able to "pull in" what else they need, by asking one or two core models for it (e.g. don't worry about passing in a model and its associations as separate variables. Pass in the model and let the view fetch the associations if needed. I've worked on systems (in fact, I'd say, unfortunately, most systems) that pass 10's, 20's, 30's of variables into a view, when many of those could simply have to been loaded on-demand by the view itself. I think Rails generally does a good job of encouraging a model-pull methodology, but I'm talking about MVC (on the web) as a broader concept.
Views can use complex logic. Some projects I've worked on thought that because something in a view was more than a simple "for each" loop, it therefore needed to be stuffed into the controller. That is wrong. Your controller is then performing view logic. The view is code... let's not hide that fact.
Relating to point (3), don't confuse "template" with "view" as a whole. The template is just part of your view.

I'm drifting off-topic here, but in short, most of your logic should probably finish up in your models. Your models, well, model your application in terms of data and how that data changes. It's therefore natural that this is where a lot of logic is placed. Your controllers only serve to transport information between the models and your end user (which just so happens, to be via the view).

Quite a long-winded way to say "I agree with John", eh? ;)

回复收藏 0 原文

~没有更多了~