Rails 模型、视图、控制器和助手：什么去哪里？

StackOverflow https://stackoverflow.com/questions/60658

题

在 Ruby on Rails 开发（或一般的 MVC）中，我应该遵循什么快速规则来放置逻辑。

请作肯定回答 - 与 请把这个放在这里, ， 而不是 不要把它放在那里.

有帮助吗？

解决方案

多维控制器

控制器:在这里放置与确定用户想要什么、决定给他们什么、确定他们是否登录、他们是否应该看到某些数据等相关的代码。最后，控制器查看请求并计算出要显示哪些数据（模型）以及要呈现哪些视图。如果您不确定代码是否应该放入控制器中，那么它可能不应该放入。保留您的控制器 瘦骨嶙峋的.

看法:视图应该只包含显示数据（模型）的最少代码，它不应该进行大量处理或计算，它应该显示由模型计算（或汇总）或从控制器生成的数据。如果您的视图确实需要执行模型或控制器无法完成的处理，请将代码放在帮助程序中。视图中的大量 Ruby 代码使页面标记难以阅读。

模型:你的模型应该在哪里 全部 与您的数据相关的代码（构成您网站的实体，例如用户、帖子、帐户、朋友等）的生活。如果代码需要保存、更新或汇总与您的实体相关的数据，请将其放在此处。它将可以在您的视图和控制器中重复使用。

其他提示

添加到 pauliephonic 的答案：

帮手:函数使创建视图变得更容易。例如，如果您总是迭代小部件列表以显示其价格，请将其放入帮助程序中（以及实际显示的部分内容）。或者，如果您有一段 RJS，您不想让视图变得混乱，请将其放入助手中。

MVC 模式实际上只关心 UI，不关心其他任何事情。您不应该在控制器中放置任何复杂的业务逻辑，因为它控制视图而不是逻辑。控制器应该关注选择正确的视图并将更复杂的东西委托给域模型（模型）或业务层。

领域驱动设计有一个服务的概念，它是一个粘贴逻辑的地方，需要编排许多不同类型的对象，这通常意味着自然不属于模型类的逻辑。

我通常将服务层视为我的应用程序的 API。我的服务层通常与我正在创建的应用程序的要求非常接近地映射，因此服务层充当应用程序较低级别中更复杂的交互的简化，即您可以绕过服务层来实现相同的目标，但您必须使用更多的手段才能使其发挥作用。

请注意，我在这里讨论的不是 Rails，而是解决您的特定问题的通用架构风格。

这里已经有完美的解释了，一句话作为结论，很容易记住：

我们需要智能模型、精简控制器和哑视图。

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

Rails 的方式是 瘦控制器和胖模型.

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

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

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

控制器用于控制哪些数据从模型到视图（以及哪个视图）以及从视图到模型。控制器也可以在没有模型的情况下存在。

我喜欢将控制器视为保安人员/接待员，他将客户（请求）引导到适当的柜台，在那里您向柜员（查看）询问问题。然后出纳员（视图）去从经理（模型）那里得到答案，而你从未见过他。您提出请求，然后返回保安/接待员（控制员）并等待，直到您被指示去另一个出纳员（视图），他告诉您经理（模型）针对其他出纳员（视图）问题告诉他们的答案。

同样，如果您想告诉出纳员（查看）某件事，那么基本上会发生相同的事情，除了第二个出纳员会告诉您经理是否接受您的信息。保安/接待员（控制员）也可能告诉您去徒步旅行，因为您无权告诉经理该信息。

因此，扩展一下这个比喻，在我的刻板印象和不切实际的世界中，出纳员（观点）很漂亮，但头脑空虚，经常相信你告诉他们的任何事情，保安/接待员几乎没有礼貌，但知识不是很丰富，但他们知道人们应该和不应该去，经理们真的很丑陋，很卑鄙，但他们知道一切，可以分辨什么是真的，什么是假的。

有助于正确分离的一件事是避免“将局部变量从控制器传递到视图”反模式。而不是这个：

# app/controllers/foos_controller.rb:
class FoosController < ApplicationController

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

end

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

尝试将其移至可用作辅助方法的 getter：

# 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”中的内容及其使用方式变得更加容易。它增加了控制器和视图之间的分离，而不使它们变得更加复杂。

嗯，这有点取决于逻辑必须处理什么......

通常，将更多的东西放入模型中，而使控制器保持较小的规模是有意义的。这确保了您可以在需要访问模型表示的数据的任何地方轻松使用此逻辑。视图应该几乎不包含逻辑。所以，总的来说，你应该努力做到这一点，这样你就不会重复自己。

另外，快速谷歌一下，就会发现一些更具体的例子，说明什么去了哪里。

模型：验证要求、数据关系、创建方法、更新方法、销毁方法、查找方法（请注意，您不仅应该拥有这些方法的通用版本，而且如果您经常做某些事情，例如通过以下方式查找红头发的人）姓氏，那么你应该提取该逻辑，以便你所要做的就是调用 find_redH_by_name("smith") 或类似的东西）

看法：这应该是关于数据格式化，而不是数据处理。

控制器：这就是数据处理的地方。来自网络：“控制器的目的是响应用户请求的操作，获取用户设置的任何参数，处理数据，与模型交互，然后以最终形式将请求的数据传递到视图。”

希望有帮助。

简单来说，一般来说，楷模 将包含与表相关的所有代码、它们的简单或复杂关系（将它们视为涉及多个表的 SQL 查询）、操作数据/变量以使用业务逻辑得出结果。

控制器 将具有指向所请求作业的相关模型的代码/指针。

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

与这些的任何重大偏差都会给该部分带来不必要的压力，并且整体应用程序性能可能会受到影响。

测试，测试……在模型中放入尽可能多的逻辑，然后您就可以正确测试它。单元测试通过测试模型来测试数据及其形成方式，功能测试通过测试控制器来测试数据的路由或控制方式，因此您无法测试数据的完整性，除非数据在该模型。

j

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top