Что такое помощник в Magento?
В каких случаях следует использовать, а не использовать помощников?
Что такое помощник в Magento?
В каких случаях следует использовать, а не использовать помощников?
Ответы:
Теоретически вы никогда не должны использовать помощников.
Помощники - это просто наборы несвязанных методов и всегда создаются как одиночные экземпляры.
Это в основном процедурное программирование с функциями, сгруппированными в некотором пространстве имен (имя класса в данном случае). Но так как в Magento есть помощники в ядре, вы можете поместить свои методы туда, чтобы вы не знали, куда их поместить или если вам нужно вызывать их во многих разных местах (модели, контроллеры, шаблоны)
Используйте их как последнее средство.
Также Magento требует помощника для каждого модуля по причинам перевода.
Вы можете просто создать помощник, вызываемый Data.php
в каждом модуле, и оставить его пустым.
Вопрос имеет два аспекта:
В общем, то , классы по имени Helper
, Util
или подобное просто говорит : « У меня есть некоторые функции , которые я не знаю , куда девать» , и не имеет особого смысла , так как класс.
Magento создает экземпляры помощников как синглтоны, и большинство основных помощников не имеют никакого состояния, поэтому методы могут быть как с классом, так static
и functions
без него. Все это часто считается запахом кода , недостатком в дизайне приложения.
Как уже указывал Мариус, вам не нужно использовать помощники для собственного кода. Просто создайте по умолчанию пустой помощник для модуля, если вы используете специфичные для модуля переводы, иначе они не будут работать. Предпочитают модели (которые не нужно расширять, Mage_Core_Model_Abstract
если они не представляют данные базы данных) или классы независимых библиотек.
Тем не менее, я бы не стал слишком строго относиться к тому, чтобы «вообще не использовать помощников», а вместо этого использовать их для ярлыков запросов, таких как:
конфигурация модуля доступа:
public function getFooBar()
{
return Mage::getStoreConfig('module/foo/bar');
}
фабричные методы для библиотечных классов
public function getNewFooService()
{
return new \Foo\Service(...);
}
Вы могли бы найти другие места, но имхо, помощник модуля часто достаточно хорош для подобных вещей.
Потребление основных помощников - это то, что вы будете делать довольно часто.
__()
метод перевода: чтобы получить перевод определенного модуля, вы должны использовать Mage::helper('module-alias')->__('string to be translated')
. Это происходит неявно, если вы используете $this->__(...)
внутри шаблона или блока, и если вы используете translate="..."
атрибут в файлах XMLMage::helper('core')
методы: локализованная дата, цена и форматирование валюты, экранирование и кодирование данныхMage::helper('tax')
методы получения информации из налоговой конфигурации и расчета цен на основе этогоMage::helper('catalog/image')
предоставляет интерфейс для создания кэшированных и измененных размеров каталожных изображений и получения их URLMage::helper('catalog/product_url_rewrite')->joinTableToSelect()
соединяет таблицу перезаписи URL с запросом к коллекции продуктов.В основных помощниках скрыто много других (более или менее) полезных функций. Если вам нужна определенная функциональность, которая, вероятно, будет использоваться где-то в ядре, проверьте, можете ли вы использовать вспомогательный метод.
Обычно эти помощники являются объектами без состояния, а методы - методами запросов (т.е. они не имеют побочных эффектов)
Но, как всегда, Magento нарушает свои неписаные правила и не должен рассматриваться как пример. «Хороший» пример того, как не использовать помощники, - Mage_Catalog_Helper_Product_Compare
это $_itemCollection
свойство, которое можно инициализировать только один раз, и $_customerId
свойство, которое можно изменить с помощью установщика. Вы найдете еще несколько помощников, связанных с каталогом с прикрепленными коллекциями. Написание тестов для кода, который использует их или повторно использует их в другом контексте, не очень весело, поэтому, пожалуйста, не делайте этого дома.
catalog/image
Помощник упоминалось выше , является еще одним примером помощника , который действительно не должен быть помощником. Вам нужно init()
сначала передать продукт, который сбрасывает его текущее состояние, затем вы устанавливаете различные параметры (например resize()
, setQuality()
), и в конце вы можете получить URL с помощью его __toString()
метода. Это выглядит хорошо, когда используется в шаблоне, но код представляет собой огромный беспорядок, и он не имеет смысла как одиночка.
TL; DR:
Reader
и Writer
моделей, которые на самом деле сделать есть состояние ( по крайней мере, файловый ресурс). Например, для чтения данных о состоянии заказа из файла CSV у меня будет sth. Лика OrderStatusCsvReader
модель, которая используется OrderStatusUpdater
моделью. Таким образом, я также разделяю проблемы «чтение данных из файла» и «порядок обновления в Magento»
Мариус прав. Я думаю, что помощники это чепуха.
Но в теории маженто вы должны поместить все в помощники, которые не изменяют состояние объекта, например, получить отформатированную цену.
Но все, что вы можете поместить в помощника, вы можете положить и в модель. И вы можете получить различные экземпляры модели, что полезно для тестирования.
Я довольно новичок в Magento, но для меня это выглядит так, как будто Helper - это эквивалент сервиса Magento : «набор связанных программных функций, которые можно повторно использовать для различных целей». Модуль экспортирует свою предлагаемую функциональность через сервисы. Используйте помощника для функций, которые вы предлагаете использовать другим модулям.
Модель должна предоставлять только методы, которые напрямую связаны с получением или установкой состояния объекта или иным образом связаны с созданным объектом модели.
Помощь полезна для предотвращения дублирования кода (в моделях, шаблонах, ...), а иногда они просто необходимы.
Mage::getStoreConfigFlag('my/module/enabled')
каждого файла, где вы хотите это проверить, или вы используете Mage::helper('my_module')->isEnabled()
с преимуществами:
isEnabled()
метод helpers, и он повлияет на все классы, которые его используют, вместо перезаписи нескольких файлов.Mage_Catalog_Model_Product
чтобы добавить метод getProductArticles()
. Верно . В свой помощник добавьgetProductArticles(Mage_Catalog_Model_Product $product)
<action method="someMethod"><var helper="module/method" /></action>
Вы можете просто создать помощник, вызываемый
Data.php
в каждом модуле, и оставить его пустым .
При использовании PHPUnit вы должны добавить одну строку :protected $_moduleName = 'My_Module';
foreach
петель и всякие безумства. Я обнаружил, что реструктурирование этой ужасающей логики для помощника и использование ее в качестве кеша объектов было полезным и оставило мало места для ошибок от будущих разработчиков, которые могли бы случайно вызватьgetModel
вместо того,getSingleton
чтобы поместить их в модель.