Magento 2: uso corretto degli helper

9

Sto iniziando a vedere sempre più persone che dichiarano le classi di aiutanti per poter utilizzare quanto segue nei file modello:

$this->helper('Path/To/Helper/Class')->customMethod();

Questo tipo di codice consente alle persone di evitare di non utilizzare direttamente la restrizione del gestore oggetti, ma tendo a vedere il codice che dovrebbe essere il codice di blocco in quegli helper.

Quindi, ecco le mie domande:

cosa si dovrebbe scrivere nelle classi di aiuto?
in quali casi è importante utilizzare i metodi di supporto nei modelli?

— Raffaello al Pianismo digitale
fonte

20

Non farlo.
È come usare ObjectManager::getInstance()->create()un modello!
Utilizzare invece un blocco personalizzato che riceve l'helper come dipendenza del costruttore e aggiungere un metodo proxy che chiama il metodo helper.

Nel modello:

$block->customMethod()

Nel blocco:

public function __construct(Path/To/Helper/Class $helperClass, ...other dependencies...)
{
    $this->helper = $helperClass;
    // ...other assignments and call to parent::__construct()
}

public function customMethod()
{
    return $this->helper->customMethod();
}

In linea di principio OOP questo evita di violare la "Legge di Demetra". Incapsula la logica aziendale nel blocco anziché nel modello. Come effetto collaterale rende anche la logica più testabile quando la logica viene spostata nel blocco.

Per quanto riguarda la logica inserita nelle classi helper, trovo che in Magento 2 gli helper abbiano principalmente senso per i servizi, come qualcosa che non è un modello, ma contiene codice riutilizzabile, ad esempio la formattazione dei prezzi (che è contenuta nel core, ma posso non pensare a un esempio migliore in questo momento).

— Vinai
fonte

Sono d'accordo con il principio, tuttavia sembra che l'utilizzo della preferenza di.xmlper il tipo di classe blocchi, non mantenga una configurazione del layout. Ho provato ad esempio a farlo per la classe \Magento\Catalog\Block\Product\View\Type\Simple, il modello default.phtmlche è stato utilizzato nel nostro modello viene ignorato. Nessun indizio sul perché al momento

— Sylvain Rayé,

2

Saltando qui per informazioni più aggiornate. A partire da 2.2, l'estensione delle classi Block non è consigliata. Invece, se è richiesta una logica di presentazione personalizzata, è necessario definire e dichiarare ViewModel come argomento per il blocco in layout.xml. Dal momento che ViewModels sono creati tramite l'Object Manager, puoi collegare il tuo grafico delle dipendenze senza esporsi ai cambiamenti di BC nelle future versioni di Magento 2.

— John Hall,

1

Vedo gli helper come funzioni globali all'interno del modulo (scusate per la parola "globale") e i contratti di gestione / servizio come funzioni globali che possono essere utilizzate sia all'interno che all'esterno del modulo.

Se segui questo principio, vedrai che c'è un uso minimo per gli helper, li uso solo come wrapper di configurazione nei miei moduli.

$this->configHelper->get(Config::PATH_TO_XML_PATH);
$this->configHelper->isEnabled();

Questo tipo di cose. Se hai altre funzionalità che potrebbero essere pratiche al di fuori del tuo modulo, crea invece un gestore.

In un mondo ideale, gli sviluppatori di terze parti che hanno bisogno della funzionalità di altri moduli dovrebbero solo cercare nelle interfacce disponibili repository e gestori e cose nella Apicartella.

— Giel Berkers
fonte