Bağımlılıkların Magento 2 CRUD / Abstract Modeline Enjekte Edilmesi


12

Magento 2 CRUD modeline bağımlılık enjekte etmek mümkün müdür?

Yani - Magento 2 baz soyut bir model sınıfı vardır: Magento\Framework\Model\AbstractModel. Basit bir Oluşturma, Okuma, Güncelleme, Silme modeli nesnesi oluşturmak istiyorsanız, bu sınıfı kendi sınıfınızla genişletirsiniz.

class Foo extends Magento\Framework\Model\AbstractModel
{
}

Modelinizin __constructyöntemine bağımlılıklar eklemek mümkün mü ? Denediğimde, aşağıdaki hatayı alıyorum.

Önemli hata: Soyut sınıf Magento \ Framework \ Model \ ResourceModel \ AbstractResource somutlaştırılamıyor

Suçlu gibi görünüyor AbstractModelbireyin __constructyöntemi.

public function __construct(
    \Magento\Framework\Model\Context $context,
    \Magento\Framework\Registry $registry,
    \Magento\Framework\Model\ResourceModel\AbstractResource $resource = null,
    \Magento\Framework\Data\Collection\AbstractDb $resourceCollection = null,
    array $data = []
) {

Bu yapıcıda ( Magento\Framework\Model\ResourceModel\AbstractResource, Magento\Framework\Data\Collection\AbstractDb) Magento nesne yöneticisi arabirimleri olmayan iki tür ipucu vardır . Bunlar soyut sınıflar. Bu sınıfı genişletip enjekte edilen bağımlılığımı eklemeye çalıştığımda

class Foo extends Magento\Framework\Model\AbstractModel
{
    public function __construct(
        \Magento\Framework\Model\Context $context,
        \Magento\Framework\Registry $registry,
        \Magento\Framework\Model\ResourceModel\AbstractResource $resource = null,
        \Magento\Framework\Data\Collection\AbstractDb $resourceCollection = null,
        array $data = [],
        \Package\Module\Model\Mine $mine,

    ) {
        //...
        parent::__construct($context, $registry, $resource, $resourceCollection, $data);

    }
}

Magento, nesne yöneticisi soyut sınıfları somutlaştırmaya çalıştığında kefaletle serbest bırakılır.

Nesneye bağımlılığımı soyut sınıfların önüne taşıyarak bunu "düzeltebilirim"

    public function __construct(
        \Magento\Framework\Model\Context $context,
        \Magento\Framework\Registry $registry,

        \Package\Module\Model\Mine $mine,

        \Magento\Framework\Model\ResourceModel\AbstractResource $resource = null,
        \Magento\Framework\Data\Collection\AbstractDb $resourceCollection = null,
        array $data = [],
    ) {  

Ancak bu, argüman sırasını değiştirdi. Tamamen nesne tarafından yönetilen bir sınıfta, bu bir sorun olmazdı. Bununla birlikte, bu soyut sınıf tipi ipuçlarının mevcut olması Magento sisteminin CRUD nesnelerini manuel olarak (yani nesne yöneticisi veya DI yoluyla değil) başlatan ve belirli bir sırayla tip ipuçlarına uyan nesnelere geçecek kısımları olduğunu ima eder .

Bu güvenli mi? Yani soyut bir modelin yapıcısındaki bu soyut sınıflar sadece eski kodlar mıdır ve kullanılmazlar mı? Yoksa sistemin bazı bölümleri hala bunları kullanacak mı, yani bir CRUD modeline bağımlılık enjekte etmek mümkün değil mi?

Yanıtlar:


9

Her şeyden önce yapıcı sınıfın özel API'sıdır. Yapıcı işlevi özel bir anlama sahiptir ve üst sınıftakiyle aynı argüman listesine / sırasına sahip olmak zorunda değildir.

Magento 2 CRUD modeline bağımlılık enjekte etmek mümkün müdür?

Evet tabi ki.

Bu güvenli mi?

Evet, ancak Magento Nesne Yöneticisi tüm isteğe bağlı parametrelerin listenin sonuna yerleştirildiğini ve isteğe bağlı sonra gerekli parametrelerin çözülmeyeceğini varsayar.

$ resource, $ resourceCollection argümanları eskidir ancak Model sınıflarında hala yaygın olarak kullanılmaktadır. Modelin çoğu kaynak ve toplama sınıfını başlatmak için böyle bir kod kullanır.

protected function _construct() { 
    $this->_init('Magento\AdminNotification\Model\Resource Model\Inbox'); 
}

Bu yüzden bu parametreler isteğe bağlıdır. Ancak, örneğin, birim testinde, gerçekleştirmenin yerine geçmesini sağlamak için yapıcıda kaynak veya koleksiyon alayını geçiyoruz.


@Kanday Magento'nun mühendislik / mimarlık departmanı, çekirdek sınıflar için kurucu siparişinin ilgisiz olduğuna dair kamuya açık bir açıklama yaptı mı? Yoksa bu sadece insanların üzerinde çalıştığı umudu mudur?
Alan Storm

Ben buna "alakasız" demeyeceğim. Sadece OM, yapıcıya gerekli argümanları iletir ve üst sınıftaki sıraya bağlı değildir. Dahası, IN parametre adlarını kullanır, bu yüzden şimdi onların değiştirilmemesi daha iyidir (parametrelerin adlarını istediğiniz gibi değiştirebileceğiniz php dilinden farklıdır)
KAndy

Ne dediğini anladığımdan emin değilim. Gelecekte bir noktada çekirdek Magento sistem kodunun argüman / parametre sırasını tekrar önemli olarak ele almaya başlayabileceğini mi söylüyorsunuz?
Alan Storm

Hayır olduğuna inanıyorum
KAndy

Tekrar teşekkürler! FWIW ve Google çalışanları için bu güvenli bir şey gibi görünüyor. Ne söyleyebilirim otomatik olarak körü körüne yapıcı parametre sırasını varsayarak bir modeli başlatan Magento sistem kodu yoktur.
Alan Storm

6

Bu güvenli görünüyor. En azından, magento bunu birçok yerde yapıyor. Örnekler için aşağıdaki (özel olmayan) sınıf listesindeki __construct yöntemlerine bakın

  • \ Magento \ Tema \ Modeli \ Tema \ Dosya
  • \ Magento'nın \ Tema \ Model \ Tasarım
  • \ Magento \ Satış \ Modeli \ al \ Alacak Dekontu

Maalesef, sorunuzun diğer kısmına cevap veremiyorum.


4
  1. Modelinizi nasıl kullanıyorsunuz?
  2. Senin durumunda $minebir olduğunu gerekli iken, parametre $resource, $resourceCollectionve $datavardır isteğe bağlı . İsteğe bağlı parametreler her zaman devam etmelidir, aksi takdirde isteğe bağlı olarak onlarla çalışmak imkansızdır. Bu yüzden, $mineisteğe bağlı parametrelerden önce belirtmeniz gerektiği bana Tamam görünüyor .

Bu soyut parametreler dışında bağımlılık enjekte parametreleri değildir ve Magento çekirdek sistem kodu orada olmasını beklerse $minekuyruğun önüne geçmek hatalar yaratacaktır. Magento çekirdek sistem kodu ise gelmez o zaman bunları kullanmak neden vardır? Bu, dibe inmeye çalıştığım soru. Modelimi taşındı parametresiyle kullanabildiğim için güvenli değil.
Alan Storm

Bazı modeller özel bir kaynak modelini iletmek için bu isteğe bağlı parametreleri kullanmaya devam edebilir. Örneğin, github.com/magento/magento2/blob/develop/app/code/Magento/…
BuskaMuza

Magento, parametrenin isteğe bağlı olup olmadığını belirlemek için yansıma kullanır. Ve PHP olarak önce gerekli parametreyi ayakta tüm parametreleri dikkate gerekli . $mineİsteğe bağlı parametrelerden önce hareket ederseniz , bunlar gerçekten isteğe bağlıdır ve Magento sadece varsayılan değerleri ( null, array()) geçirir . İsteğe bağlı parametrelerden sonra gerekli bir parametreyi koyarsanız, PHP isteğe bağlı parametreleri gerektiği gibi kabul eder ve Magento bunları başlatmaya çalıştı (ancak onlar için herhangi bir tercih yoktur).
BuskaMuza

Her ne kadar kafa karıştırıcı göründüğüne katılıyorum ve belki de soyut sınıflar için model sınıfında kullanmak yerine bir tercih ayarlayabiliriz. Böylece her zaman gerçek bir nesne enjekte edilir.
BuskaMuza
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.