热门：培训标准变量字符串环境数字数据工具名称基础工作密码信息设备元素单位管理文件位置标签应用程序学习文档设置服务状态

关于ruby：Rails模型，视图，控制器和助手：什么去了？

2023-04-15 05:25:00

关于ruby：Rails模型，视图，控制器和助手：什么去了？

Rails Model, View, Controller, and Helper: what goes where?

在Ruby on Rails开发(或通用MVC)中，关于放置逻辑的位置，我应该遵循什么快速规则。

请回答是肯定的-用Do将其放在此处，而不要将其放在此处。

MVC

控制器：将代码放入此处，该代码与确定用户的需求，确定给他们的内容，确定他们是否已登录，是否应该看到某些数据等有关。最后，控制器查看请求并计算出要显示的数据(模型)和要呈现的视图。如果您不确定代码是否应放入控制器中，则可能不应该这样做。使您的控制器保持瘦身。

视图：视图仅应包含用于显示数据(模型)的最少代码，不应进行大量处理或计算，而应显示由模型计算(或汇总)或由控制器生成的数据。如果您的视图确实需要执行模型或控制器无法完成的处理，则将代码放入帮助器中。视图中的大量Ruby代码使页面标记难以阅读。

模型：模型应该是与数据相关的所有代码(构成您网站的实体，例如用户，帖子，帐户，朋友等)所在的地方。如果代码需要保存，更新或汇总与您的实体相关的数据，请放在此处。它可以在您的视图和控制器之间重复使用。

要补充pauliephonic的答案：

助手：使创建视图更容易的功能。例如，如果您总是在小部件列表上进行迭代以显示其价格，则将其放入帮助器中(连同部分用于实际显示)。或者，如果您有不想使视图混乱的RJS，请将其放入帮助器中。

MVC模式实际上仅与UI有关，而与其他无关。您不应该在控制器中放置任何复杂的业务逻辑，因为它控制视图，而不是逻辑。财务主任应考虑选择正确的视图，并将更复杂的内容委派给域模型(模型)或业务层。

域驱动设计具有服务的概念，在这里您需要坚持逻辑，逻辑需要编排许多不同类型的对象，这通常意味着逻辑自然不属于Model类。

我通常将服务层视为应用程序的API。我的服务层通常非常接近我正在创建的应用程序的需求，因此服务层可以简化我的应用程序较低层中发现的更复杂的交互，即，您可以绕过服务层来实现相同的目标但您必须拉更多的杠杆才能使其正常工作。

请注意，我在这里不是在谈论Rails，而是在讨论解决您的特定问题的通用体系结构样式。

这里已经有了完善的解释，一个非常简单的句子作为结论，并且容易记住：

We need SMART Models, THIN Controllers, and DUMB Views.

http://c2.com/cgi/wiki?ModelViewController

务必将与授权/访问控制相关的内容放入控制器中。

模型都是关于您的数据的。验证，关系，CRUD，业务逻辑

视图是关于显示数据的。仅显示和获取输入。

控制器是关于控制哪些数据从模型到视图(以及哪个视图)以及从视图到模型的数据。控制器也可以不带模型而存在。

我喜欢将控制器视为安全护卫/接待员，将您的客户(请求)引导至相应的柜台，您在此询问柜员(查看)问题。然后，出纳员(视图)从您从未见过的经理(模型)那里得到答案。您的请求然后返回到保安员/接待员(控制器)，并等待直到您被指示转到另一个柜员(视图)，后者告诉您经理(模型)对另一个柜员(视图)问题的回答。

同样，如果您想告诉出纳员(视图)某事，则除第二个出纳员会告诉您经理是否接受您的信息外，基本上会发生相同的事情。由于您无权告诉管理员该信息，因此保安人员/接待员(控制器)也可能已经告诉您要远足。

因此，为了扩大这个比喻，在我刻板的，不切实际的世界中，出纳员(视图)很漂亮，但是头脑呆滞，并且经常相信您告诉他们的任何内容，安全警卫/接待员虽然礼貌却很少，但是知识渊博，但是他们知道人们应该在哪里以及不应该去，管理者真的很丑，很卑鄙，但是知道一切，可以说出什么是真的，什么不是。

Rails的方法是拥有瘦的控制器和胖模型。

帮助正确分离的一件事是避免使用"从控制器传递局部变量到视图"反模式。代替这个：

1
2
3
4
5
6
7
8
9
10
11
12
13
# app/controllers/foos_controller.rb:
class FoosController < ApplicationController

  def show
    @foo = Foo.find(...)
  end

end

#app/views/foos/show.html.erb:
...
<%= @foo.bar %>
...

尝试将其移至可作为辅助方法使用的吸气剂：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# app/controllers/foos_controller.rb:
class FoosController < ApplicationController

  helper_method :foo

  def show
  end

  protected

  def foo
    @foo ||= Foo.find(...)
  end

end

#app/views/foos/show.html.erb:
...
<%= foo.bar %>
...

这使修改" @foo"中的内容及其使用方式变得更加容易。它增加了控制器和视图之间的间隔，而不会使其变得更加复杂。

好吧，这取决于要处理的逻辑...

通常，将更多的内容推入模型中，而使控制器变小是有意义的。这样可以确保可以在需要访问模型表示的数据的任何位置轻松使用此逻辑。视图应该几乎没有逻辑。因此，总的来说，实际上，您应该努力做到这一点，以免您重复自己。

另外，快速浏览一下Google还会发现一些具体的例子。

模型：验证需求，数据关系，创建方法，更新方法，销毁方法，查找方法(请注意，您不仅应拥有这些方法的通用版本，而且还应做很多事情，例如寻找有红色背景的人头发按姓氏命名，那么您应该提取该逻辑，以便您要做的就是调用find_redH_by_name(" smith")或类似的东西)

视图：这应该全部与数据格式有关，而不是数据处理。

控制器：这是数据处理的地方。在互联网上："控制器的目的是响应用户请求的操作，获取用户设置的任何参数，处理数据，与模型进行交互，然后将请求的数据以最终形式传递给用户。视图。"

希望能有所帮助。

简单来说，
模型将具有与表相关的所有代码，它们的简单或复杂关系(将它们视为涉及多个表的sql查询)，使用业务逻辑对数据/变量进行操作以得出结果。

管制员将拥有针对所要求工作的相关模型的代码/指针。

视图将接受用户输入/交互并显示结果响应。

与这些内容的任何重大偏差都将对该部分造成不必要的负担，并且可能会影响整个应用程序性能。

测试，测试...
在模型中放置尽可能多的逻辑，然后就可以对其进行正确的测试。单元测试通过测试模型来测试数据及其形成方式，而功能测试则通过测试控制器来测试路由或控制方式，因此得出结论，除非数据在内部，否则您将无法测试数据的完整性。该模型。

?

控制器视图模型通用

推荐阅读