2

我越来越多地将我所有的代码放在有关 MVC 的模型和助手中。

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

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

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

结尾

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

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

4

3 回答 3

5

您的具体示例包括一个业务规则，即如果模型的实例既被购买又被确认，那么正确的状态是“购买”而不是“确认”

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

一个不同的例子：

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

在这种情况下，status_string 方法可以在 View Helper 或 Model 中合理定义——它与任何业务规则无关，它正在更改值的表示。我将它放在模型中，因为我倾向于只将与 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
于 2010-05-03T03:52:48.560 回答
3

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

例如：

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

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

在性能方面，您不会看到使用助手和模型之间有任何显着差异。提取状态对象的数据库往返更有可能成为瓶颈。

于 2010-05-03T03:52:37.680 回答
0

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

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

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

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

ST_PENDING = 1

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

MyModel.all(:status=>ST_PENDING)

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

MyModel::STATUS[obj.status]
于 2011-01-10T00:08:51.173 回答