Должен ли я избежать проверки на ноль в представлениях Rails? - PullRequest
7 голосов
/ 12 ноября 2008

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

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

Должен ли я вернуть 0 вместо нуля? Есть ли какой-либо другой шаблон, который я мог бы использовать, чтобы избежать множества нулевых проверок в моих представлениях?

Ответы [ 4 ]

8 голосов
/ 12 ноября 2008

Я склонен думать, что вы все делаете правильно, если ваша проблема заключается в выборе: отображать или не отображать результаты расчета. Если не имеет смысла отображать какое-либо значение, тогда ноль вполне разумен.

Если, однако, ваша бизнес-логика приводит к тому, что вы попадаете в состояние, при котором большая часть представления будет обычно пустой, то вам, вероятно, следует выполнить рефакторинг так, чтобы ваша программа теряла свои утечки абстракций.

Рассмотрим, например, приложение, которое запускается с отслеживания рецептов для Food. Затем, по мере изменения требований, мы получаем представление о пирогах, которые должны отображать информацию, отличную от бургеров. Вместо того, чтобы иметь метод calculate_deliciousness_of_pie_or_nil_for_burger, а затем проверять на ноль в представлении, я разбил бы это на представление пирогов для пирогов и представление бургеров для бургеров. Это может (вероятно, потребует) переосмыслить абстракции моего объекта.

3 голосов
/ 12 ноября 2008

«Я делаю много нулевых проверок, прежде чем отображать эти значения в моих представлениях.»

Я думаю, что возвращать ноль - хорошая идея. Альтернативой, которую я иногда использую, является возвращение хэша. Например, если метод завершился успешно, я мог бы вернуть:

{:result => 1234}

и, если метод "потерпел неудачу", я мог бы вернуть:

{:error => 'Insufficient attributes to calculate result.'}

Это упрощает определение результата, не угадывая.

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

<% if result = some_method -%>
  Your result is <%=h result -%>.<br />
<% end -%>

Вы должны сделать это:

<% display_some_method %>

и метод #display_ some_ находится в app / helpers / what_helper.rb.

2 голосов
/ 12 ноября 2008

Этот ТАК вопрос может дать вам некоторое представление о структуре нуля или нуля:

Лучшая идиома Ruby для «ноль или ноль»

1 голос
/ 26 декабря 2008

Я атакую ​​эту проблему, используя два подхода.

Я пытаюсь перенести более требовательные проверки в модель. Например, метод Apartment#address_visible?(current_user) делает его намного чище.

Начиная с Rails 2.3, существует также метод #try, который вызывает метод, только если он уже определен. Он может быть легко включен в ваш проект, используя chris ' пример . Это для самых простых случаев.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...