Magento 2：正确使用助手

9

我开始看到越来越多的人声明帮助程序类，以便能够在模板文件中使用以下内容：

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

这种代码使人们避免不直接使用对象管理器的限制，但是我倾向于在那些帮助器中看到应该是块代码的代码。

所以这是我的问题：

在助手类中应该写些什么？
在哪些情况下在模板中使用辅助方法是否有意义？

— 拉斐尔在数字钢琴家
source

20

别。
这就像ObjectManager::getInstance()->create()在模板中使用！
使用自定义的Block接收帮助者作为构造函数依赖项，并添加一个调用该helper方法的代理方法。

在模板中：

$block->customMethod()

在块中：

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

用OOP原则来说，这避免了违反“得墨meter耳法则”。它将业务逻辑封装在模块中，而不是模板中。副作用是，随着逻辑被移入模块，它也使逻辑更具可测试性。

关于将什么逻辑放入帮助程序类中，我发现在Magento 2中，帮助程序主要对服务有意义，例如不是模型而是包含可重用代码的东西，例如价格格式（包含在核心中，但是我可以现在还没有想到一个更好的例子）。

— 维奈
source

我同意这一原则，但是看起来像在di.xml块类类型中使用首选项，不要保留某些布局配置。例如，我尝试为该类\Magento\Catalog\Block\Product\View\Type\Simple执行default.phtml此操作，我们模板中使用的模板被忽略。暂时不知道为什么

— SylvainRayé'May

2

在此处跳转以获取更多最新信息。从2.2开始，不建议扩展Block类。相反，如果需要自定义表示逻辑，则应定义一个ViewModel并将其声明为layout.xml中Block的参数。由于的ViewModels通过对象管理器内置，你就可以将你自己的依赖关系图中不暴露自己BC重大更改在Magento 2的未来版本

— 约翰·霍尔

1

我将助手视为模块内部的全局函数（对不起，单词“ global”一词），而经理/服务合同则视为允许在模块内部和外部使用的全局函数。

如果遵循此原则，您会发现帮助程序的使用最少，我仅将它们用作模块中的配置包装器。

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

这种东西。如果您在模块之外还具有其他实用的功能，则可以创建一个管理器。

在理想情况下，需要其他模块功能的第三方开发人员只需要查看可用的界面，即可找到存储库和管理器以及-文件Api夹中的内容。

— 吉尔·伯克斯
source