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

请以肯定的答案回答"不要在此放置"。

解决方案

回答

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

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

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

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

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

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

希望能有所帮助。

回答

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

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

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

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

回答

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

回答

MVC

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

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

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

回答

要补充pauliephonic的答案：

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

回答

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

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

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

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

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

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

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

回答

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

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

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

end

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

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

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

回答

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

Ĵ