Qual è lo scopo dell'oggetto di contesto nel costruttore DI di qualsiasi classe? Come funziona il contesto?

23

Nella maggior parte dei costruttori della classe, viene passato un oggetto Context. Non riuscivo a capire come funzionasse questo Context Obj. Ho anche notato che a volte questo viene passato al costruttore della classe genitore come di seguito.

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

Puoi spiegare come funziona questo specifico contesto?

magento2 architecture

— allievo
fonte

30

Nota che ci sono diversi oggetti di contesto, in questo caso è \Magento\Framework\App\Action\Contexte per capirlo, dovresti leggerlo come "ActionContext". Rappresenta il contesto dell'applicazione in cui viene eseguita l'azione. In altre parole, consente di accedere a tutti gli oggetti con lo stato dell'applicazione necessario per un'azione del controller, ad esempio il registro o l'oggetto richiesta.

Le classi di contesto non hanno funzionalità proprie, sono solo un contenitore per altri oggetti. Puoi vederli come scorciatoia per non avere 20 parametri in ogni azione del controller. Tutti i parametri comuni vengono uniti nell'oggetto contesto.

— Fabian Schmengler
fonte

come potrei sapere quali oggetti sono contenuti da diversi $context?

— LucScu,

@LucaS guarda il loro codice sorgente. Le classi contenute si trovano nel costruttore del contesto

— Fabian Schmengler,

15

Sono stati introdotti oggetti di contesto per isolare gli sviluppatori di terze parti dai cambiamenti nei costruttori di classi astratte.

In Magento 1 le classi astratte con un sacco di comportamento "helper" erano considerate un'API conveniente per l'estensione di classe. Questo ha causato un gran numero di metodi e dipendenze implicite in classi astratte ( AbstractModel, AbstractBlock, AbstractAction)

In Magento 2 le API basate sull'ereditarietà (più precisamente SPI) sono scoraggiate, ma esistono ancora molte API legacy. Inizialmente abbiamo pianificato di rimuovere gradualmente comportamenti extra dalle classi astratte. E per non spezzare tutti gli extender quando avremmo rimosso alcune dipendenze dal costruttore, abbiamo introdotto gli oggetti Context.

Il piano attuale prevede di abbandonare le API basate sull'ereditarietà con API basate sull'interfaccia a un certo punto.

— Anton Kril
fonte