Magento 2ヘルパーインスタンス

Magento 2のDIシステムに頭を巻きつけたと思うと、何かが出てきて、包みを解きます。
ヘルパーにアクセスするさまざまな方法をコアコードで確認します。
たとえば、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でのヘルパーのインスタンス化。これはそれに関するフォローアップの質問です。

オブジェクトマネージャを使用することはすでにデメテルの法則に違反しているため、可能な限りDIを使用することをお勧めします。オブジェクトマネージャを使用する場合、これらの依存関係はメソッドロジックで非表示になるだけです。

Magentoの実装についてはあまり知りませんが、これObjectManagerはService Locatorのようです。

一般に、Service Locatorを使用してオブジェクトの依存関係にアクセスするのはかなり悪いです。この記事をチェックしてください。

コンストラクタを介して依存関係を明示的に定義する方がはるかに優れたアプローチです。定義されていないサービスの単体テストと実行時の問題に役立ちます。

オブジェクトマネージャーをクラスに注入することは、基本的に、すべてのアプリケーションサービスにアクセスできるクラスにレジストリを注入することですが、これは明らかに正しくありません。

私が使用しZF2に公平なビットを、一般的に、依存関係を必要とするサービス、コントローラおよび任意のクラスのための小さな工場のクラスを定義します。これらのファクトリクラスはサービスロケータにアクセスし、オブジェクトが依存するすべてのサービスを取得し、コンストラクタを通じてそれらを注入します。それは主に、何かのコードを捨てているようファクトリクラスのサービスロケータを使用することは結構です、この例を。

これらの工場はまだテストが簡単です。

IMO、可能な限りコンストラクター注入を使用します。繰り返しますが、私はMagentoの実装についてあまり詳しくありません。ファクトリーの概念がある場合、一見するとそれらをサポートしているように見えますが、クラスを明示的に定義し、Service Locatorを使用してそれらをFactoryクラスで構築することはよりクリーンなアプローチ。

これは上記のパターンへの露出が限られている人からのものですので、この件に関する他の人の考えや経験も聞きたいです！

もっと読む

• http://ralphschindler.com/2012/10/10/di-dic-service-locator-redux

（テンプレートで）ヘルパーを使用するもう1つの方法は次のとおりです。

$this->helper('[Vendor]\[Module]\Helper\[Helper Name]')->getMethodName();

まだご存じない方にもお役に立てれば幸いです。

それは古い質問ですが、私がいるかどうかわからないんだけどマリウスはその答えを得ました。マリウスはもっとよく答えられると思います。一言でお答えしたいと思います。Magento 2がヘルパーの代わりにDIの使用を提案するのはなぜですか？

• 単体テストでの分離を可能/簡単にする
• クラスの依存関係を明示的に定義する
• 優れた設計の促進（単一責任原則（SRP）など）
• モジュールでDIを使用すると、Magentoがこれらのインターフェースの基本的な実装を変更した場合の非互換性バグのリスクが軽減されます。これは、拡張機能の開発者が理解する重要な概念です。

M2コアがDIを使用しない場合があるのはなぜですか？

• クラス数の減少
• 不要なインターフェースを作成しない
• 非互換性バグのリスクなし

コアカタログモジュールはヘルパーとして使用されていますが、DIを幅広く使用しています。私の調査では、Magento 2がコアカタログヘルパーファイルのサービス契約に適さない機能をいくつか使用していることがわかりました。

Magento定義のクラス（\ Magento \ Catalog \ Model \ Productなど）を明示的に使用する必要がある場合は、サービスコントラクトインターフェイスではなく具体的​​な実装に応じて、暗黙的な依存関係を明示的に指定します。

間違いなく、拡張機能の開発者はヘルパーのようなMagento1の代わりにDIを使用する必要があります。Magento 2のガイドラインに従って実装すると、フォールアウトが制限されます。推奨事項を破ると、問題が発生します。