Когда я думаю, что обернул голову вокруг системы DI из Magento 2, что-то появляется и разворачивается.
Я вижу в основном коде разные способы доступа к помощнику.
Например, Magento\Catalog\Controller\Category::_initCategoryтам есть это:
if (!$this->_objectManager->get('Magento\Catalog\Helper\Category')->canShow($category)) {
return false;
}Но в Magento\Catalog\Block\Category\Viewпомощник вводится конструктор
public function __construct(
\Magento\Framework\View\Element\Template\Context $context,
\Magento\Catalog\Model\Layer\Category $catalogLayer,
\Magento\Framework\Registry $registry,
\Magento\Catalog\Helper\Category $categoryHelper,
array $data = array()
) {
$this->_categoryHelper = $categoryHelper;
$this->_catalogLayer = $catalogLayer;
$this->_coreRegistry = $registry;
parent::__construct($context, $data);
}Это привело меня к мысли, что к помощникам следует обращаться по-разному в контроллерах и блоках (и моделях), но затем я нашел контроллер, в который в конструктор вводится помощник Magento\Catalog\Controller\Adminhtml\Product\Action\Attribute.
Пожалуйста, очистите туман для меня.
Когда я должен использовать DI и когда я должен использовать objectManager? и почему?
Я прочитал этот вопрос: Создание помощников в Magento 2 . Это просто дополнительный вопрос по этому вопросу.
источник
Я не так много знаю о реализации Magento, но похоже, что
ObjectManagerэто Service Locator .Как правило, использование Service Locator для доступа к зависимостям в объекте довольно плохо, ознакомьтесь с этой статьей .
Явное определение ваших зависимостей через конструктор - гораздо лучший подход. Это помогает в модульном тестировании и проблемах во время выполнения с сервисами, которые не определены.
Внедрение диспетчера объектов в класс - это внедрение реестра в ваш класс, который имеет доступ ко всем службам ваших приложений, что, очевидно, неправильно.
Я пользуюсь ZF2 и обычно определяю небольшие фабричные классы для Сервисов, Контроллеров и любого класса, который требует зависимостей. Эти фабричные классы имеют доступ к локатору службы и получают все службы, от которых зависит объект, и внедряют их через конструктор. Использование Service Locator в классе Factory хорошо, так как он в основном отбрасывает код, например, как этот .
Эти фабрики все еще легко проверить .
IMO, используйте конструктор инъекций там, где это возможно. Опять же, я не знаю слишком много о реализации Magento и, если она имеет концепцию Factories, с первого взгляда она выглядит так, как будто она их поддерживает, но явное определение ваших классов и использование Service Locator для их построения в классах Factory - это гораздо чище подход.
Это от кого-то, кто имеет ограниченное воздействие вышеупомянутых шаблонов, поэтому я также хотел бы услышать мысли / опыт других по этому вопросу!
Больше чтения
источник
Еще один способ использовать помощник (в шаблонах):
Я надеюсь, что это полезно, если вы еще не знали.
источник
Хотя это старый вопрос, я не уверен, что Мариус получил ответ. Я верю, что Мариус может ответить лучше. Я хотел бы ответить на это вкратце. Почему Magento 2 предлагает использовать DI вместо помощника?
Почему ядро M2 может не использовать DI в некоторых случаях?
Хотя модуль каталога Core использовался как вспомогательный, он широко использовал DI. В своем исследовании я обнаружил, что Magento 2 использует несколько функций в файлах вспомогательного каталога Core, которые не подходят для контрактов на обслуживание.
Если вам необходимо явно использовать Magento-определенный класс (например, \ Magento \ Catalogue \ Model \ Product), сделайте явную зависимость явной, полагаясь на конкретную реализацию вместо интерфейса контракта на обслуживание.
Несомненно, разработчик расширений должен использовать DI вместо Magento1, как Helper. При реализации в соответствии с рекомендациями Magento 2, последствия ограничены. При нарушении рекомендаций возникают проблемы.
источник