Magento 2: правильное использование помощников

9

Я начинаю видеть, что все больше и больше людей объявляют классы помощников, чтобы иметь возможность использовать следующее в файлах шаблонов:

$this->helper('Path/To/Helper/Class')->customMethod();

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

Итак, вот мои вопросы:

что нужно писать во вспомогательных классах?
в каких случаях уместно использовать вспомогательные методы в шаблонах?

— Рафаэль в цифровом пианизме
источник

20

Не.
Это похоже на использование ObjectManager::getInstance()->create()в шаблоне!
Вместо этого используйте пользовательский блок, который получает помощника в качестве зависимости конструктора, и добавьте прокси-метод, который вызывает метод помощника.

В шаблоне:

$block->customMethod()

В блоке:

public function __construct(Path/To/Helper/Class $helperClass, ...other dependencies...)
{
    $this->helper = $helperClass;
    // ...other assignments and call to parent::__construct()
}

public function customMethod()
{
    return $this->helper->customMethod();
}

В принципе ООП это позволяет избежать нарушения "Закона Деметры". Он инкапсулирует бизнес-логику в блоке вместо шаблона. В качестве побочного эффекта это также делает логику более тестируемой при перемещении логики в блок.

Что касается логики, заложенной в вспомогательные классы, я обнаружил, что в Magento 2 помощники в основном имеют смысл для сервисов, например, для чего-то, что не является моделью, но содержит повторно используемый код, например форматирование цены (которое содержится в ядре, но я могу не думаю о лучшем примере прямо сейчас).

— Vinai
источник

Я согласен с принципом, однако, похоже, что использование предпочтений di.xmlдля блоков класса типа, не сохраняйте некоторые настройки макета. Я попытался, например, сделать это для класса \Magento\Catalog\Block\Product\View\Type\Simple, шаблон, default.phtmlкоторый использовался в нашем шаблоне, игнорируется.

— Понятия не

2

Прыжки сюда для получения более актуальной информации. Начиная с 2.2 расширение классов блоков не рекомендуется. Вместо этого, если требуется пользовательская логика представления, ViewModel должен быть определен и объявлен как аргумент для Block в layout.xml. Поскольку ViewModels создаются с помощью диспетчера объектов, вы можете подключить свой собственный граф зависимостей, не подвергая себя воздействию BC, нарушающему изменения в будущих выпусках Magento 2.

— Джон Холл,

1

Я вижу помощников как глобальные функции внутри вашего модуля (извините за слово «глобальный»), а менеджеров / сервисные контракты - как глобальные функции, которые разрешено использовать как внутри, так и за пределами вашего модуля.

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

$this->configHelper->get(Config::PATH_TO_XML_PATH);
$this->configHelper->isEnabled();

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

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

— Гиль Беркерс
источник