Magento 2: bon usage des aides

9

Je commence à voir de plus en plus de personnes déclarer des classes d'aides afin de pouvoir utiliser ce qui suit dans les fichiers de modèle:

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

Ce type de code permet aux gens d'éviter la restriction de ne pas utiliser directement le gestionnaire d'objets, mais j'ai tendance à voir du code qui devrait être du code bloc dans ces assistants.

Donc, voici mes questions:

que faut-il écrire dans les classes d'assistance?
dans quels cas est-il pertinent d'utiliser des méthodes d'assistance dans les modèles?

— Raphael chez Digital Pianism
source

20

Non.
C'est comme utiliser ObjectManager::getInstance()->create()dans un modèle!
Utilisez à la place un bloc personnalisé qui reçoit l'aide en tant que dépendance de constructeur et ajoutez une méthode proxy qui appelle la méthode d'assistance.

Dans le modèle:

$block->customMethod()

Dans le bloc:

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

Dans le principe de la POO, cela évite de violer la "loi de Déméter". Il encapsule la logique métier dans le bloc au lieu du modèle. En tant qu'effet secondaire, cela rend également la logique plus testable lorsque la logique est déplacée dans le bloc.

En ce qui concerne la logique mise dans les classes d'assistance, je trouve que dans Magento 2, les assistants ont principalement un sens pour les services, comme quelque chose qui n'est pas un modèle, mais contient du code réutilisable, par exemple le formatage des prix (qui est contenu dans le noyau, mais je peux pense pas à un meilleur exemple en ce moment).

— Vinai
source

Je suis d'accord avec le principe, mais il semble que l'utilisation de la préférence di.xmlpour le type de classe de blocs ne conserve pas une configuration de mise en page. J'ai essayé par exemple de le faire pour la classe \Magento\Catalog\Block\Product\View\Type\Simple, le template default.phtmlqui était utilisé dans notre template est ignoré. Aucune idée pourquoi pour le moment

— Sylvain Rayé

2

Sautez ici pour des informations plus à jour. Depuis la version 2.2, l'extension des classes Block n'est pas recommandée. Au lieu de cela, si une logique de présentation personnalisée est requise, un ViewModel doit être défini et déclaré en tant qu'argument au bloc dans layout.xml. Étant donné que les ViewModels sont construits via le gestionnaire d'objets, vous pouvez câbler votre propre graphique de dépendance sans vous exposer aux changements de rupture de la Colombie-Britannique dans les futures versions de Magento 2.

— John Hall

1

Je vois les assistants comme des fonctions globales à l'intérieur de votre module (désolé pour le mot «global»), et les gestionnaires / contrats de service comme des fonctions globales qui peuvent être utilisées aussi bien à l'intérieur qu'à l'extérieur de votre module.

Si vous suivez ce principe, vous verrez qu'il y a une utilisation minimale pour les assistants, je ne les utilise que comme wrapper de configuration dans mes modules.

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

Ce genre de choses. Si vous avez d'autres fonctionnalités qui pourraient être pratiques en dehors de votre module, créez plutôt un gestionnaire.

Dans un monde idéal, les développeurs tiers qui ont besoin de fonctionnalités d'autres modules ne devraient avoir qu'à chercher dans les interfaces disponibles pour les référentiels et les gestionnaires et des trucs dans le Apidossier.

— Giel Berkers
source