Ketika saya pikir saya mendapatkan kepala saya melilit sistem DI dari Magento 2, sesuatu muncul dan melepaskannya.
Saya melihat dalam kode inti berbagai cara untuk mengakses pembantu.
Misalnya Magento\Catalog\Controller\Category::_initCategory
ada ini:
if (!$this->_objectManager->get('Magento\Catalog\Helper\Category')->canShow($category)) {
return false;
}
Tetapi dalam Magento\Catalog\Block\Category\View
helper disuntikkan ke konstruktor
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);
}
Ini membuat saya berpikir bahwa para pembantu harus diakses secara berbeda di dalam pengontrol dan blok (dan model) tetapi kemudian saya menemukan sebuah pengontrol di mana seorang pembantu dimasukkan ke dalam konstruktor Magento\Catalog\Controller\Adminhtml\Product\Action\Attribute
.
Tolong bersihkan kabut untuk saya.
Kapan saya harus menggunakan DI dan kapan saya harus menggunakan objectManager
? dan mengapa?
Saya telah membaca pertanyaan ini: Instantiating Helpers in Magento 2 . Ini hanya pertanyaan lanjutan untuk itu.
sumber
Saya tidak tahu banyak tentang implementasi Magento, tetapi sepertinya
ObjectManager
ini adalah Locator Layanan .Umumnya menggunakan Service Locator untuk mengakses dependensi pada suatu objek cukup buruk, periksa artikel ini .
Mendefinisikan ketergantungan Anda secara eksplisit melalui konstruktor adalah pendekatan yang jauh lebih baik. Ini membantu dalam pengujian unit dan menjalankan masalah waktu dengan layanan yang tidak ditentukan.
Menyuntikkan Object Manager ke kelas pada dasarnya menyuntikkan Registry ke kelas Anda yang memiliki akses ke semua layanan aplikasi Anda, yang jelas tidak benar.
Saya menggunakan ZF2 sedikit adil dan umumnya mendefinisikan kelas pabrik kecil untuk Layanan, Pengendali dan setiap kelas yang membutuhkan dependensi. Kelas-kelas pabrik ini memiliki akses ke Service Locator dan ambil semua layanan yang bergantung pada objek, dan menyuntikkan mereka melalui konstruktor. Menggunakan Service Locator di kelas Factory baik-baik saja karena sebagian besar membuang kode, misalnya seperti ini .
Pabrik-pabrik ini masih mudah diuji .
IMO, Gunakan injeksi konstruktor jika memungkinkan. Sekali lagi, saya tidak tahu terlalu banyak tentang implementasi Magento dan jika memiliki konsep Pabrik, dari sekilas itu terlihat seperti mendukung mereka, tetapi secara eksplisit mendefinisikan kelas Anda dan menggunakan Penunjuk Lokasi Layanan untuk membangunnya di kelas Pabrik adalah pendekatan yang jauh lebih bersih.
Ini dari seseorang yang memiliki paparan terbatas pada roti yang disebutkan di atas, jadi saya juga ingin mendengar pikiran / pengalaman orang lain tentang masalah ini!
Lebih banyak membaca
sumber
Salah satu cara lain untuk menggunakan helper (dalam templat) adalah:
Saya harap ini berguna jika Anda belum tahu.
sumber
Meskipun ini adalah pertanyaan lama, saya tidak yakin apakah Marius mendapatkan jawabannya. Saya percaya Marius bisa menjawabnya dengan lebih baik. Saya ingin menjawab singkatnya. Mengapa Magento 2 menyarankan untuk menggunakan DI bukan pembantu?
Mengapa M2 core mungkin tidak menggunakan DI dalam beberapa kasus?
Meskipun modul Core catalog telah digunakan helper, ia telah menggunakan DI secara ekstensif. Dalam penelitian saya, saya menemukan Magento 2 menggunakan beberapa fungsi dalam file pembantu Katalog Core yang tidak cocok untuk Kontrak Servis.
Jika Anda harus secara eksplisit menggunakan kelas yang ditentukan Magento (seperti \ Magento \ Catalog \ Model \ Product), buat dependensi implisit secara eksplisit dengan bergantung pada implementasi konkret alih-alih antarmuka kontrak layanan.
Tidak diragukan lagi, pengembang ekstensi harus menggunakan DI bukan Magento1 seperti Helper. Saat menerapkan sesuai dengan pedoman Magento 2, dampaknya terbatas. Ketika melanggar rekomendasi, masalah terjadi.
sumber