Co to jest __construct i _construct w magento2?


21

W Magento 2 większość klas ma te dwie konstrukcje ( __constructi _construct) metody. Jaka jest różnica między nimi?

Odpowiedzi:


17

Nie jestem do końca pewien, czy zmieniło się to między Magento 1 i Magento 2, prawdopodobnie nie, więc pójdę z tym, co wiem z Magento 1.

_constructZostanie wywołana po__construct

Natywna __constructmetoda PHP nie powinna być nadpisywana ani używana w kodzie. Jeśli chcesz wykonać kod w bezpieczny sposób na początku klasy, użyj _construct.

Magento użyje języka macierzystego, __constructaby upewnić się, że wszystko jest „gotowe” do użycia klasy, na przykład zdefiniować odpowiednie znaczniki pamięci podręcznej dla określonego modelu.


15

Metoda _construct była „wynalazkiem Varien” stosowanym do zawarcia logiki inicjalizacji w modelach, pomocnikach i blokach.

Dlatego niezwykła jest zmiana lub ponowna deklaracja natywnej metody __construct () w modelach / blokach M1 lub pomocnikach, ponieważ zawsze korzystamy z fabryk Magento. Jednak nie ma żadnych problemów / złych praktyk dotyczących korzystania z niego (jeśli zależy Ci na kompatybilności).

W M2 metoda _construct () nadal występuje w niektórych częściach i jest używana do tych samych celów, ale teraz (w M2) cała logika DI jest implementowana przez __constructor (), więc w bazie kodu znajdziesz wiele deklaracji konstrukcyjnych.

BTW, nie ma już takich fabryk jak Mage::getModel()w M2.

Innymi słowy:

Metoda _construct () jest implementowana przez Magento w niektórych klasach i jest wywoływana automatycznie w deklaracji funkcji __construct , więc jeśli rozszerzasz klasę Magento jak Model, możesz użyć jej do wykonania pewnych rzeczy po utworzeniu obiektu.

W modelu zasobów lub klasie modelu należy zdefiniować _construct()metodę w celu zdefiniowania tabeli i klucza podstawowego

Z drugiej strony __construct jest rodzimą metodą PHP (wszystkie języki OO mają taką), __constructwywoływaną za każdym razem, gdy tworzysz obiekt. To wszystko

Przykład:

Magento \ Framework \ Model \ ResourceModel \ AbstractResource

/**
 * Abstract resource model
 */
abstract class AbstractResource
{
    /**
     * Main constructor
     */
    public function __construct()
    {
        /**
         * Please override this one instead of overriding real __construct constructor
         */
        $this->_construct();
    } ...

Magento \ Framework \ Model \ ResourceModel \ Db \ AbstractDb

/**
 * Class constructor
 *
 * @param \Magento\Framework\Model\ResourceModel\Db\Context $context
 * @param string $connectionName
 */
public function __construct(\Magento\Framework\Model\ResourceModel\Db\Context $context, $connectionName = null)
{
    $this->transactionManager = $context->getTransactionManager();
    $this->_resources = $context->getResources();
    $this->objectRelationProcessor = $context->getObjectRelationProcessor();
    if ($connectionName !== null) {
        $this->connectionName = $connectionName;
    }
    parent::__construct();
}

Czy możesz podać przykład?
zed Blackbeard

W M2? mogę poprawić odpowiedź, aby wyjaśnić różnicę, ale nie wiem, czy potrzebny jest przykład,
MauroNigrele

Interesuje mnie twoja opinia na temat czegoś związanego z DI i __construct (). Wydaje się, że tak zwana „logika DI” w Magento2 jest zaimplementowana jako anty-wzór, ponieważ w rzeczywistości tworzy ścisłe sprzężenie. Uruchomienie aktualizacji kompozytora, w zależności od liczby modułów strony 3D, które zostały rozszerzone o moduły, może często prowadzić do debugowania, dodawania parametrów w konstruktorach, które tak naprawdę nie są używane w klasach potomnych, tylko po to, aby aplikacja działała. Nie jestem pewien, czy powinno się to nawet nazywać „wstrzykiwaniem zależności”, ale zakotwiczenie zależności lub coś w tym stylu…
someGuyOnTheWeb,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.