それでは、昨日、Magentoコミュニティの他の人たちとinクラス/テンプレートの直接的な使用ObjectManager
に関して大きな話をしました。
Alan Kentを引用して、ObjectManagerを直接使用しない理由をすでに知っています。
いくつかの理由があります。コードは機能しますが、ObjectManagerクラスを直接参照しないことがベストプラクティスです。
- そう言うから!;-)(一貫性のあるコードは良いコードとして表現される方が良い)
- コードは、将来、異なる依存性注入フレームワークで使用される可能性があります
- テストが簡単になります。モックObjectManagerを提供することなく、必要なクラスのモック引数を渡すことができます。
- 依存関係をより明確に保ちます -コードの途中で依存関係を非表示にするのではなく、コンストラクターリストを介してコードが依存するものが明らかです
- カプセル化やモジュール化などの概念をプログラマーがよりよく考えるように促します -コンストラクターが大きくなった場合、コードがリファクタリングを必要とする兆候かもしれません
StackExchangeで私が見たものから、多くの人々は、たとえば次のような簡単/短い/推奨されない解決策を求める傾向があります。
<?php
//Get Object Manager Instance
$objectManager = \Magento\Framework\App\ObjectManager::getInstance();
//Load product by product id
$product = $objectManager->create('Magento\Catalog\Model\Product')->load($id);
痛みを伴うが推奨されるプロセスを経る代わりに:
- モジュールを作成する
- 設定の宣言
- 依存関係を注入する
- パブリックメソッドを宣言する
ただし、ジレンマが発生します。Magento2コアファイルは、多くの場合ObjectManagerを直接呼び出します。ここに簡単な例があります:https : //github.com/magento/magento2/blob/develop/app/code/Magento/GoogleOptimizer/Block/Adminhtml/Form.php#L57
だからここに私の質問があります:
- なぜMagentoは私たちにしないことを勧めているのですか?それは、
ObjectManager
直接使用する必要がある場合があることを意味しますか?もしそうなら、それらのケースは何ですか? - ObjectManagerを直接使用した結果はどうなりますか?
The intent of zend-servicemanager is for use as an Inversion of Control container. It was never intended as a general purpose service locator [...]
。M2にも当てはまります。There are valid use cases
セクションも確認してください。これもここに適用されます。