Magento 2 Yardımcı örneği

Kafamı Magento 2'den DI sisteminin etrafına sardığımı düşündüğümde bir şey ortaya çıkıyor ve çözülüyor.
Çekirdek kodda bir yardımcıya erişmek için farklı yollar görüyorum.
Örneğin Magento\Catalog\Controller\Category::_initCategoryburada:

if (!$this->_objectManager->get('Magento\Catalog\Helper\Category')->canShow($category)) {
    return false;
}

Ama Magento\Catalog\Block\Category\Viewyardımcıya yapıcıya enjekte edilir

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);
}

Bu bana yardımcıların kontrolörlerde ve bloklarda (ve modellerde) farklı şekilde erişilmesi gerektiğini düşündürdü, ancak daha sonra yapıcıya bir yardımcı enjekte edildiği bir kontrolör buldum Magento\Catalog\Controller\Adminhtml\Product\Action\Attribute.

Lütfen benim için sisi temizleyin.
Ne zaman DI kullanmalıyım ve ne zaman kullanmalıyım objectManager? ve neden?
Bu soruyu okudum: Magento 2'deki Yardımcıları Oluşturma . Bu sadece bununla ilgili bir soru.

Mümkün olduğunda DI'yi tercih ederim, çünkü nesne yöneticisini kullanmak zaten demeter yasalarına aykırıdır. Nesne yöneticisini kullanırken bu bağımlılıklar yöntem mantığında gizlidir.

Magento uygulaması hakkında çok şey bilmiyorum, ama ObjectManagerbir Servis Bulucu gibi görünüyor .

Genellikle bir nesnedeki bağımlılıklara erişmek için bir Servis Bulucu kullanmak oldukça kötüdür, bu makaleye göz atın .

Bağımlılıklarınızı bir kurucu aracılığıyla açıkça tanımlamak çok daha iyi bir yaklaşımdır. Ünite testine ve tanımlanmayan servislerle çalışma süresi sorunlarına yardımcı olur.

Nesne Yöneticisi'ni bir sınıfa enjekte etmek, temel olarak, sınıfınıza tüm uygulama hizmetlerinize erişimi olan bir kayıt defteri enjekte eder, ki bu doğru değildir.

Kullandığım ZF2 adil biraz ve genellikle Hizmetleri Kontrolörleri ve bağımlılıkları gerektiren herhangi bir sınıf için küçük fabrika sınıfları tanımlar. Bu fabrika sınıfları Servis Bulucu'ya erişebilir ve nesnenin bağlı olduğu tüm hizmetleri alır ve bunları kurucu aracılığıyla enjekte eder. Çoğunlukla, böyle bir şey kodunu atmak gibi bir fabrika sınıfında Servis Bulucu Kullanımı gayet bu örneğin.

Bu fabrikaların test edilmesi hala kolaydır .

IMO, Mümkün olan yerlerde yapıcı enjeksiyonu kullanın. Yine, Magento'nun uygulaması hakkında çok fazla şey bilmiyorum ve Fabrikalar kavramına sahipse, hızlı bir bakıştan onları destekliyor gibi görünüyor, ancak sınıflarınızı açıkça tanımlamak ve bunları Fabrika sınıflarında oluşturmak için bir Servis Bulucu kullanmak çok daha temiz bir yaklaşım.

Bu, yukarıda bahsedilen desenlere sınırlı maruz kalan birinden, bu yüzden başkalarının konuyla ilgili düşüncelerini / deneyimlerini duymak istiyorum!

Daha fazla okuma

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

Yardımcıyı (şablonlarda) kullanmanın başka bir yolu:

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

Umarım henüz bilmediyseniz faydalıdır.

Eski bir soru olmasına rağmen, Marius'un cevabını alıp almadığından emin değilim . Marius'un daha iyi cevap verebileceğine inanıyorum . Kısaca cevaplamak istiyorum. Magento 2 neden yardımcı yerine DI kullanılmasını öneriyor?

• Birim testinde izolasyonu mümkün / kolay hale getirmek
• Bir sınıfın bağımlılıklarını açıkça tanımlama
• İyi tasarımı kolaylaştırmak (örneğin, tek sorumluluk ilkesi (SRP))
• Modülünüzde DI kullanımı Magento bu arayüzlerin temel uygulamalarını değiştirdiğinde uyumsuzluk hataları riskini azaltır. Bu, uzantı geliştiricileri için anlaşılması gereken önemli bir kavramdır.

M2 çekirdeği neden bazı durumlarda DI kullanmıyor?

• Sınıf sayısında azalma
• Gereksiz arayüzler yaratmamak
• Uyumsuzluk hatası riski yok

Core katalog modülü yardımcı kullanılmasına rağmen DI'yi yoğun olarak kullanmıştır. Araştırmamda Magento 2'nin Temel Katalog yardımcı dosyalarında Servis Sözleşmeleri için uygun olmayan birkaç işlev kullandığını gördüm.

Magento tanımlı bir sınıfı (\ Magento \ Catalogue \ Model \ Product gibi) açıkça kullanmanız gerekiyorsa, hizmet sözleşmesi arabirimi yerine somut uygulamaya bağlı olarak örtük bağımlılığı açıkça belirtin.

Şüphesiz, uzantı geliştiricisi Yardımcı gibi Magento1 yerine DI kullanmalıdır. Magento 2'nin kurallarına göre uygularken, serpinti sınırlıdır. Öneriler kırılırken sorunlar meydana gelir.