Jaki jest cel obiektu kontekstowego w konstruktorze dowolnej klasy DI? Jak działa kontekst?

23

W większości konstruktorów klasy przekazywany jest obiekt Context. Nie mogłem zrozumieć, jak działa ten kontekst kontekstowy. Zauważyłem również, że czasami jest to przekazywane konstruktorowi klasy nadrzędnej, jak poniżej.

public function __construct(
    \Magento\Framework\App\Action\Context $context,
    \Magento\Catalog\Model\Design $catalogDesign,
    \Magento\Catalog\Model\Session $catalogSession,
....
    parent::__construct(
        $context,
        $layoutFactory,

Czy możesz wyjaśnić, jak działa ten konkretny obiekt kontekstowy?

magento2 architecture

— uczeń
źródło

30

Zauważ, że istnieją różne obiekty Context, w tym przypadku jest to \Magento\Framework\App\Action\Contexti aby je zrozumieć, powinieneś przeczytać go jako „ActionContext”. Reprezentuje kontekst aplikacji, w którym wykonywane jest działanie. Innymi słowy, daje dostęp do wszystkich obiektów ze stanem aplikacji, których potrzebuje akcja kontrolera, na przykład rejestru lub obiektu żądania.

Klasy kontekstu nie mają własnej funkcjonalności, są tylko kontenerem dla innych obiektów. Możesz zobaczyć je jako skrót, aby nie mieć 20 parametrów w każdej akcji kontrolera. Wszystkie wspólne parametry są scalane w obiekcie kontekstu.

— Fabian Schmengler
źródło

skąd mam wiedzieć, który obiekt zawiera inny $context?

— LucScu,

@LucaS spójrz na ich kod źródłowy. Zawarte klasy znajdziesz w konstruktorze kontekstu

— Fabian Schmengler,

15

Obiekty kontekstowe zostały wprowadzone w celu odizolowania programistów zewnętrznych od zmian w konstruktorach klas abstrakcyjnych.

W Magento 1 klasy abstrakcyjne z wieloma zachowaniami „pomocniczymi” były uważane za wygodne API dla ekstendera klas. Wywołało to ogromne liczby metod i ukrytych zależności w abstrakcyjnych klas ( AbstractModel, AbstractBlock, AbstractAction)

W Magento 2 interfejsy API oparte na dziedziczeniu (a dokładniej SPI) są odradzane, ale wiele starszych interfejsów API wciąż istnieje. Początkowo planowaliśmy stopniowe usuwanie dodatkowych zachowań z klas abstrakcyjnych. Aby nie łamać wszystkich ekstenderów, kiedy usuwamy pewną zależność od konstruktora, wprowadziliśmy obiekty Context.

Obecny plan polega na porzuceniu interfejsów API opartych na dziedziczeniu interfejsów API opartych na interfejsie.

— Anton Kril
źródło