Стратегия дизайна - вспомогательные методы, которые бросают исключения
-
16-10-2019 - |
Вопрос
Я внедряю плагин для клиента, который будет использовать стоимость «максимальной продажи» акции Magento на продукт в качестве средства установки верхней части общей покупки клиентов.
Поскольку мне нужно проверить это условие в нескольких событиях, действиях контроллера, я не могу сдержать его только для наблюдателя, где я мог бы создать локальную защищенную функцию, которая проверяет это условие из моей модели ресурса.
В своих требованиях я буду ограничивать дополнения тележки. Но я нахожусь в дилемме: от контроллера addAction
Мне нужно полагаться на throw
- Однако от sales_quote_merge_before
Похоже, я мог бы эффективно снять оскорбительные продукты и опубликовать сообщение в customer/session
, Однако я мог бы бросить и поймать соответственно, как и с действием контроллера.
Мои вопросы:
- Эта плохая практика, чтобы эффективно полагаться на
throw
от помощника модуля? - Это, скорее, модельный метод, который мне нужен?
- Какую лучшую стратегию дизайна позволяет мне сохранить свой модуль сухим?
Редактировать:
По состоянию на EE 1.12 я вижу только 4 экземпляра Helper/Data.php
Файлы, которые бросают - 3 из них являются API2/OAuth. Маг/Core делает это и один раз, но это кажется единственным другим экземпляром. Различные третьи стороны выглядят так, как будто они используют здесь разные подходы.
Любые отзывы приветствуются.
Решение
Сказать клиенту: «Мы извиняемся, вы не можете купить так много» - это исключение. Ожидаемое дело в том, что их достаточно, и вы помещаете продукты в корзину. И еще одно слово: есть попытка поймать блоки внутри Magento, например, в \Mage_Checkout_CartController::addAction
:
// [...]
} catch (Mage_Core_Exception $e) {
if ($this->_getSession()->getUseNotice(true)) {
$this->_getSession()->addNotice(Mage::helper('core')->escapeHtml($e->getMessage()));
// [...]
Позвольте мне сказать это так: они там, чтобы быть использованными :-)