Rails：助手和模型 - 在哪里组织代码

Question

我越来越多地将所有代码放入有关 MVC 的模型和帮助程序中。

然而，有时我不确定在哪里组织代码。它应该进入模型还是应该进入助手。各有什么好处。是一个更快还是它们相同。我听说过所有模型都会被缓存，所以看起来这将是放置我的大部分代码的更好地方。

例如，这是一个在模型或帮助程序中工作的场景：

 def status
  if self.purchased
   "Purchased"
  elsif self.confirmed
   "Confirmed"
  elsif self.reserved
   "Reserved"
  else
   "Pending"
  end

结束时

，我不需要像在数据库中那样保存此状态，因为有用于购买、确认和保留的布尔字段。那么为什么要把它放在模型中或者为什么要把它放在助手中呢？

因此，我不确定将代码放入模型或助手（如果可以同时放入两者中）的最佳实践或好处。

Answer 1

您的具体示例包括一条业务规则，即如果模型的实例均已购买并确认，则正确的状态是“已购买”而不是“已确认”

所以在您的示例中，我肯定会将方法放入模型中因为它正在编码您的应用程序业务规则之一。

另一个示例：

def status_string
  case status
    when 0: "Purchased"
    when 1: "Confirmed"
    else
      "Pending"
   end
end

在这种情况下，可以在视图帮助程序或模型中合理地定义 status_string 方法 - 它与任何业务规则无关，它正在更改值的表示形式。我将其放入模型中，因为我倾向于只将与 html 相关的 sw 放入视图助手中。但根据您的国际化方案，类似的方法可能更好地放置在视图助手中。

View Helper 的一个很好的例子是一种应用程序范围的方法，用于将日期时间值转换为应用程序的标准表示形式。例如

# application_helper.rb
def date_long_s(d)
  d.strftime("%A, %b *%d, %Y *%I:%M %p")
end

Answer 2

这确实是主观的，我同意，有时不清楚某些东西是否属于模型或助手。

例如：

# using model
status ? status.nice_name : "Pending" 
# using helper 
nice_name(status) 

助手的明显优势是它可以优雅地处理 nil 对象，保持视图干净。缺点是代码现在位于远离模型的不同位置 从

性能角度来看，您不会看到使用帮助程序和模型之间有任何显着差异。拉取状态对象的数据库往返更有可能成为瓶颈。

Answer 3

在这种情况下我使用常量哈希。

哈希在模型文件中定义，如下所示

STATUS = {
 1 => "Pending",
 2 => "Confirmed" 
}

我还为每个状态声明常量，如下所示。

ST_PENDING = 1

在编写查询时声明这一点很有用。例如，

MyModel.all(:status=>ST_PENDING)

数据库表中的状态字段是数字。所以在打印时，我就简单地使用这个。

MyModel::STATUS[obj.status]