Rails: помощники и модели - где организовать код

Все больше и больше я помещаю весь свой код в модели и помощники, касающиеся MVC.

Однако иногда я не уверен, где организовать код. Должен ли он войти в модель или в помощник. Каковы преимущества каждого. Один быстрее или они такие же. Я слышал кое-что о том, что все модели кэшируются, поэтому мне кажется, что это было бы лучшим местом для размещения большей части моего кода.

Например, вот сценарий, который работает в модели или в помощнике:

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

конец

Мне не нужно сохранять этот статус, как в базе данных, потому что есть логические поля для купленных, подтвержденных и зарезервированных. Так зачем использовать это в модели или в помощнике?

Поэтому я не уверен в лучшем опыте или преимуществах, полученных от помещения кода в модель или в помощник, если это может быть и в том, и в другом.


ruby ruby-on-rails organization model-view-controller
person thenengah    schedule 03.05.2010    source источник

Ответы (3)


arrow_upward
5
arrow_downward

Ваш конкретный пример включает бизнес-правило в том смысле, что если экземпляр модели приобретен и подтвержден, то надлежащий статус будет «куплен», а не «подтвержден».

Итак, в вашем примере я бы определенно включил метод в модель, поскольку он кодирует одно из бизнес-правил ваших приложений.

Другой пример:

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

В этом случае метод status_string можно разумно определить либо в View Helper, либо в модели - он не имеет ничего общего с какими-либо бизнес-правилами, он меняет представление значения. Я бы поместил это в модель, так как я обычно помещаю SW-файлы, связанные с HTML, в View Helpers. Но в зависимости от вашей схемы интернационализации аналогичный метод лучше разместить в View Helper.

Хорошим примером View Helper является общесистемный метод преобразования значений даты и времени в стандартное представление вашего приложения. Например

# application_helper.rb
def date_long_s(d)
  d.strftime("%A, %b *%d, %Y *%I:%M %p")
end
person Larry K    schedule 03.05.2010
comment
+1 за - я бы определенно включил метод в модель, поскольку он кодирует одно из бизнес-правил ваших приложений. - person Srikanth Venugopalan; 03.05.2010
comment
еще +1 за все, что сказал Виски. - person Anurag; 18.06.2010

arrow_upward
3
arrow_downward

Это действительно субъективно, и я согласен, иногда неясно, принадлежит ли что-то модели или помощнику.

Например:

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

Явным преимуществом здесь для помощника является то, что он может обрабатывать нулевые объекты, сохраняя чистоту представлений. Недостаток в том, что код теперь находится в другом месте, вдали от модели.

С точки зрения производительности вы не увидите значительной разницы между использованием помощников и моделей. Более вероятно, что обходы базы данных для извлечения объектов состояния будут узким местом.

person Sam Saffron    schedule 03.05.2010

arrow_upward
0
arrow_downward

В таких ситуациях я использую постоянные хеши.

Хеш определяется в файле модели следующим образом

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

Я также объявляю константы для каждого такого статуса.

ST_PENDING = 1

Заявление об этом полезно при написании запросов. Например,

MyModel.all(:status=>ST_PENDING)

Поле статуса в таблице базы данных - это число, поэтому при печати я просто использую его.

MyModel::STATUS[obj.status]
person Metin    schedule 10.01.2011