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

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

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对象，保持视图清洁。缺点是代码现在位于远离模型的不同位置

性能方面，您不会发现使用帮助程序和模型之间存在任何显着差异。更糟糕的是DB往返拉动状态对象将成为瓶颈。

Answer 3

在这种情况下我使用恒定的哈希值。

哈希在模型文件中定义，如此

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

我也为每个状态声明常量。

ST_PENDING = 1

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

MyModel.all(:status=>ST_PENDING)

数据库表中的状态字段是数字。所以在打印时，我只是使用它。

MyModel::STATUS[obj.status]

Rails：助手和模型 - 组织代码的位置

3 个答案: