Magento 2: ordnungsgemäße Verwendung von Helfern

9

Ich sehe immer mehr Leute, die Helferklassen deklarieren, um Folgendes in den Vorlagendateien verwenden zu können:

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

Diese Art von Code ermöglicht es den Leuten, die Einschränkung des Objektmanagers nicht direkt zu verwenden , aber ich neige dazu, Code zu sehen, der Blockcode in diesen Helfern sein sollte.

Also hier sind meine Fragen:

Was soll man in den Hilfsklassen schreiben?
In welchen Fällen ist es relevant, Hilfsmethoden in den Vorlagen zu verwenden?

— Raphael beim digitalen Pianismus
quelle

19

Tu es nicht.
Dies ist wie ObjectManager::getInstance()->create()in einer Vorlage!
Verwenden Sie stattdessen einen benutzerdefinierten Block, der den Helfer als Konstruktorabhängigkeit empfängt, und fügen Sie eine Proxy-Methode hinzu, die die Helfer-Methode aufruft.

In der Vorlage:

$block->customMethod()

Im Block:

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();
}

Im OOP-Prinzip wird dadurch vermieden, dass das "Gesetz von Demeter" verletzt wird. Es kapselt die Geschäftslogik im Block anstelle der Vorlage. Als Nebeneffekt macht es die Logik auch testbarer, wenn die Logik in den Block verschoben wird.

In Bezug auf die Logik, die in die Hilfsklassen eingefügt wurde, finde ich, dass Helfer in Magento 2 meistens für Dienste sinnvoll sind, beispielsweise für etwas, das kein Modell ist, aber wiederverwendbaren Code enthält, zum Beispiel Preisformatierung (die im Kern enthalten ist, aber ich kann Ich denke momentan nicht an ein besseres Beispiel.

— Vinai
quelle

Ich bin mit dem Prinzip einverstanden, sehe jedoch so aus, als würde die Verwendung der Präferenz di.xmlfür den Blockklassentyp keine Layoutkonfiguration beibehalten. Ich habe zum Beispiel versucht, dies für die Klasse zu tun. \Magento\Catalog\Block\Product\View\Type\SimpleDie Vorlage, default.phtmldie in unserer Vorlage verwendet wurde, wird ignoriert. Keine Ahnung warum im Moment

— Sylvain Rayé

2

Hier finden Sie weitere aktuelle Informationen. Ab 2.2 wird das Erweitern von Blockklassen nicht empfohlen. Wenn stattdessen eine benutzerdefinierte Präsentationslogik erforderlich ist, sollte ein ViewModel definiert und als Argument für den Block in layout.xml deklariert werden. Da ViewModels über den Objektmanager erstellt werden, können Sie Ihr eigenes Abhängigkeitsdiagramm verkabeln, ohne sich in zukünftigen Versionen von Magento 2 BC-Änderungen auszusetzen.

— John Hall

1

Ich sehe Helfer als globale Funktionen innerhalb Ihres Moduls (Entschuldigung für das Wort "global") und Manager / Serviceverträge als globale Funktionen, die sowohl innerhalb als auch außerhalb Ihres Moduls verwendet werden dürfen.

Wenn Sie diesem Prinzip folgen, werden Sie feststellen, dass Helfer nur minimal verwendet werden. Ich verwende sie nur als Konfigurations-Wrapper in meinen Modulen.

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

Diese Art von Sachen. Wenn Sie andere Funktionen haben, die außerhalb Ihres Moduls praktisch sein könnten, erstellen Sie stattdessen einen Manager.

In einer idealen Welt sollten Entwickler von Drittanbietern, die Funktionen anderer Module benötigen, nur in den verfügbaren Schnittstellen nach Repositorys und Managern sowie nach ApiInhalten im Ordner suchen müssen.

— Giel Berkers
quelle