Модульная система Magento 2

- Magento 2

Magento состоит из нескольких различных компонентов: тем, модулей, библиотек, пакетов языков. Фреймворк Magento включает в себя библиотеки, PHP код и различные базовые концепции, которые наследуются компонентами системы.

Модули и темы в Magento используются в качестве элементов кастомизации: модули наделяют сайт разными особенностями и свойствами, темы влияют на внешний вид. Как у модулей, так и у тем есть свой жизненный цикл, который позволяет устанавливать, отключать и удалять эти элементы.

модульная система magento 2

'

Модули могут быть взаимосвязаны. При этом их зависимость должна быть такой, при которой отключение одного модуля приводит к минимальным последствиям. Помимо взаимодействия между собой, модули также взаимодействуют с темами.

Каждый модуль образует логическую группу, состоящую из блоков, хелперов, контроллеров и моделей (php и xml файлов). Каждая такая группа является независимой. Таким образом, модульный подход приводит к тому, что каждый модуль обладает своими уникальными свойствами и особенностями и минимально зависит от других модулей, а его отключение не влияет на работу других модулей.

Все модули находятся в директории /app/code. Здесь /app/code/Magento/Customer можно найти пользовательские модули (Сustomer Magento) . В папке находится код, кроме того, там можно найти конфигурации всех модулей, а также etc/module.xml файлы, которые содержат следующую информацию: имя модуля, версию, все его зависимости.

Имя и декларирование модулей

Каждый модуль декларируется в файле module.xml, найти который можно в <root>/app/code/<Vendor>/<ModuleName>/etc/. Называть модули необходимо, учитывая схему Namespace_Module: где “Namespace” – имя производителя (продавца) модуля, а “Module” – имя, данное модулю производителем (продавцом).

Информация, которую необходимо декларировать:

  • Полное имя
  • Зависимости

Пример выглядит так:

Зависимости модулей

Концепция зависимостей играет очень важную роль в Magento: все модули собираются в логические группы с уникальными особенностями. Таким образом, несколько разных модулей не могут выполнять одну и ту же функцию, а один модуль не может выполнять несколько функций. Не забывайте, что все зависимости необходимо задекларировать. При этом, отключение или удаление одного модуля не должно привести к отключению или удалению других модулей. Модули могут быть зависимыми от таких компонентов как: другие модули, PHP расширения и библиотеки.

Обязательно сохраняйте всю историю работы модуля перед его удалением.

Работа с зависимостями сводится к 3 ключевым пунктам:

  1. Сначала необходимо назвать и задекларировать модуль.
  2. Затем необходимо задекларировать зависимости
  3. Помимо этого также можно указать порядок закгруки.

 

Декларирование зависимостей

Все зависимости указаны в файле composer.json каждого модуля. Пример применения:

 

Порядок загрузки зависимостей

Чтобы указать порядок загрузки зависимостей, необходимо воспользоваться элементом <sequence> файла module.xml.

<sequence> является необязательным элементом, и используется только в том случае, если задействованы модули и необходимо указать порядок. Для других типов компонентов секция <sequence> не применяется. Не забывайте, что не все составляющие модуля, указанного в <sequence>, будут использоваться. Файлы Config и certain в директориях /view и /etc рассматриваются для специального порядка загрузки. Находясь в списке <sequence>, классы в рамках модуля не поддаются влиянию выделенного модуля.

Базовый синтаксис:

Пример использования

Magento\Customer\etc\module.xml

Элемент <sequence>  файла module.xml  используется для того, чтобы определить порядок загрузки зависимостей. Используйте файл composer.json для декларации зависимостей.

Внедрение зависимостей

Внедрение зависимостей означает, что все зависимости передаются к объекту, а не объект самостоятельно вытаскивает их из окружающей среды.

Зависимости указывают насколько сильно один компонент нуждается в других компонентах для выполнения своих функций. Чем больше у компонента зависимостей, тем сложнее его перенести в другой проект.

Менеджер объектов показывает все зависимости. Использовать его необходимо при работе с кодом.

 

Виды зависимостей модулей

В Magento у модулей существует два типа зависимости: сильная и слабая.

  1. 1.    Модули с сильной зависимостью не могу выполнять свои функции без других модулей, от которых они зависят.\.
  2. 2.    Модули со слабой зависимостью могут работать самостоятельно.

Если один модуль использует код другого модуля, то такую зависимость необходимо четко описать.

Последовательность установки: сначала устанавливаем модули, от которых зависит выбранный модуль, затем устанавливаем выбранный модуль

Неуместные зависимости

Всегда избегайте следующих зависимостей:

  • Прямых и непрямых круговых зависимостей
  • Неправильных зависимостей
  • Незадекларированных зависимостей

Существует много правил для построения зависимостей между модулями с разных уровней (layer).

Для явной зависимости можно использовать модули с уровня framework на уровне application.

Модули с уровня application не могут быть задействованы на уровне framework.

Чобы построить зависимости между классами на уровне application, необходимо использовать классы одного модуля. Чтобы построить зависимости между модулями уровня application необходимо использовать (SPI) уровня service.

API- и SPI-специализированные интерфейсы

Используйте API и SPI, чтобы построить правильные зависимости.  API-специализированные интерфейсы (декларируются с аннотацией @api) могут быть использованы другими модулями; SPI-специализированные интерфейсы (декларируются с аннотацией @spi) могут быть реализованы другими модулями.

API-специализированные интерфейсы:

Для упомянутого выше примера интерфейс со всеми его воплощениями автоматически становится частью API, в то же время другие элементы остаются в собственности модуля . Все API классы должны быть задекларированы при помощи final, чтобы предотвратить их скрытое использование в SPI.

SPI-специализированные интерфейсы:

 

Для упомянутого выше примера интерфейс автоматически становится частью SPI, в то же время его воплощения не относятся ни к SPI, ни к API. Другие интерфейсы и их воплощения, которые не указаны как SPI-специализированные, остаются в собственности модуля.

Разработчики могут воплощать SPI-специализированные интерфейсы и использовать их в конфигурациях внедрения зависимостей.

API- и SPI-специализированные интерфейсы (декларируются при помощи @api и @spi):

Чтобы обеспечить правильное поведение, необходимо разделить класс на финальный (часть API) и интерфейс реализации (implementation interface  – часть SPI).

Модули и области

Модули определяют не только ресурсы, которые видимы и доступны в области, но и указывают поведение области.

Magento состоит из 6 областей:

  • adminhtml – Magento Admin
  • frontend – Storefront
  • webapi_rest – Web API REST
  • webapi_soap – Web API SOAP
  • doc

Каждая область со своими ресурсами декларирует себя внути определенного модуля. Для каждого модуля возможно отключать ту или иную область. При включенном модуле вы вводите маршрутизаторы области в процесс маршрутизации общего применения. При выключенном модуле маршрутизаторы не загружаются, а это означает, что ресурсы становятся недоступными..

Модуль не должен быть зависим от области другого модуля.

Magento использует области, чтобы осуществлять эффективные веб-сервис звонки (web service calls), в то время как зависимый код области загружается. Frontend, backend, и webapi являются примерами областей. Основная цель всего этого – увеличение эффективности. Каждая область обладает своим поведением и набором компонентов, которые функционируют отдельно.

Области в модулях

Модули определяют видимые и доступные ресурсы в области, а также поведение области. Один модуль может оказывать влияние на несколько областей. Например, RMA представлен как в adminhtml, так и во frontend.

Отключая область, вы не отключаете модуль, который с ней связан.

Основные правила для местонахождения и названия

 

Для местонахождения модулей, а также их названий, существуют опредленные правила. Используйте Coding Standards, чтобы найти ответы на все возникшие по этому поводу вопросы.

Стандарты местоположения

 

объект местоположение
код модуля <root>/app/code/<Vendor>/<Module>
файлы темы <root>/app/design/<Module>/<theme>
библиотека <root/lib/<Vendor_Library>

Стандарты для названий

Для названий, состоящих из нескольких слов, необходимо использовать заглавные буквы для каждого слова и писать все слова слитно. Что касается псевдонимов (alias), то тут картина следующая: для псевдонима “catalogsearch” полное имя выглядит “Magento_CatalogSearch”.

Платежные модули

Реализация

В Magento платежные методы обладают следующей структурой: так часть, которая носит название abstract logic common находится в отдельном модуле, воплощения каждого отдельного метода находятся в соответствующих модулях, которые сгрупированы по типу или платежному средству. Таким образом, отключить ненужный платежный метод можно, отключив соответствующий модуль.

Включение и отключение платежных модулей

Модуль Функции Комментарии
Magento_Paypal все платежные методы PayPal:

  • Payments Advanced
  • PayPal Standard
  • Payflow Pro
  • Payments Pro
  • Payflow Link
  • PayPal Express
Можно включать/отключать. Чтобы отключить Magento_Paypal, отключите также и Magento_RecurringPayment модуль.
Magento_Payment
  • Использует абстрактную логику
  • платежная система Zero Subtotal Checkout.
не предназначен для отключения. Для отключения необходимо деактивировать все модули, которые зависимы от Magento_Payment. Чтобы найти все зависимости, перейдите к app/code/Magento/<module>/etc/module.xml и проверьте область под <depends/>.
Magento_Ogone Платежная система Ogone. Можно включать/отключать.
Magento_OfflinePayments Следующие платежные ситемы:

  • Cash on Delivery
  • Bank Transfer Payment
  • Check/Money Order
  • Purchase Order
  • Credit Card
  • Zero Subtotal Checkout payment method configuration.
Можно включать/отключать.
Magento_Authorizenet Платежные системы Authorize.Net Direct Post и Authorize.Net Можно включать/отключать.

 

 

'