Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 7
Вообще magento отказались от прямой имплементации апишных интерфейсов моделями. Более гибкий подход с Data-объектами, наследованными, например, от \Magento\Framework\Api\AbstractExtensibleObject, это позволяет добавлять дополнительные данные в API, не изменяя код модуля.
Подробный пример реализации можно подсмотреть в модуле Magento_Customer
Подробный пример реализации можно подсмотреть в модуле Magento_Customer
А можно, пожалуйста, какой-нибудь пруф, где написано, что в мадженте отказались от этого? Все, что я нашел, это вот эта статья (только для версии 2.1), где написано:
и чуть ниже для моделей:
А сущности модулей Magento_Sales, Magento_Catalog, Magento_Quote по-прежнему имплементируют интерфейсы.
We recommend you put data model classes in the Model/Data directory inside your module’s root directory.
и чуть ниже для моделей:
A model class might have a data interface implementation.
А сущности модулей Magento_Sales, Magento_Catalog, Magento_Quote по-прежнему имплементируют интерфейсы.
1. Вообще всмысле отказались? Если я не ошибаюсь, то пример разделение «Api Data Object»/ «Old Active Record Model» применен только в привеленном Вами модуле Magento_Customer. Если мы посмотрим на предлагаемый разработчиками свежий модуль, соответствующий последним течениям Magento_Inventory/Magento_InventoryApi, то там будет применен подход как в статье. Используется общий класс, имплементирующий как интерфейс DTO из API так и унаследованный от AR модели.
2. Чтобы позволить сторонним модулям расширять функционал через Extension Attributes не обязательно от кого-то наследоваться, имплементация дело второе, про которую не знает сторонний модуль. Достаточно чтобы ваш DTO имплементировал интерфейс \Magento\Framework\Api\ExtensibleDataInterface. (если этого по каким-то причинам не достаточно, то это технический долг). Для примера в указанном выше модуле Inventory класс имплементирующий интерфейс DTO наследуется от Magento\Framework\Model\AbstractExtensibleModel (которая уже имплементит \Magento\Framework\Api\ExtensibleDataInterface) github.com/magento-engcom/msi/blob/2.3-develop/app/code/Magento/Inventory/Model/SourceItem.php
3. Extension Attributes это не про персист сущностей в бд (то, что существует конфиг extension_attributes.xml с настройками таблиц и джоинами это имхо дырка в абстракции и уровнях приложения). Вы можете впринципе расширять сущность, которая не персистится никак в хранилище.
PS. Возможно maghamed нам прояснит ситуацию
2. Чтобы позволить сторонним модулям расширять функционал через Extension Attributes не обязательно от кого-то наследоваться, имплементация дело второе, про которую не знает сторонний модуль. Достаточно чтобы ваш DTO имплементировал интерфейс \Magento\Framework\Api\ExtensibleDataInterface. (если этого по каким-то причинам не достаточно, то это технический долг). Для примера в указанном выше модуле Inventory класс имплементирующий интерфейс DTO наследуется от Magento\Framework\Model\AbstractExtensibleModel (которая уже имплементит \Magento\Framework\Api\ExtensibleDataInterface) github.com/magento-engcom/msi/blob/2.3-develop/app/code/Magento/Inventory/Model/SourceItem.php
3. Extension Attributes это не про персист сущностей в бд (то, что существует конфиг extension_attributes.xml с настройками таблиц и джоинами это имхо дырка в абстракции и уровнях приложения). Вы можете впринципе расширять сущность, которая не персистится никак в хранилище.
PS. Возможно maghamed нам прояснит ситуацию
сорри, только сейчас заметил ваш диалог.
В целом Вы isxam все правильно написали.
Magento отказалась от наследования DTO классов от Magento\Framework\Api\AbstractExtensibleObject, и сейчас новый код, в частности новые модули Inventory, используют наследование от Magento\Framework\Model\AbstractExtensibleModel.
Основную неразбериху, думаю вызвало то, что класс AbstractExtensibleObject помечен как `@api`, в то время как AbstractExtensibleModel не имеет соответствующей пометки.
Вчера на внутреннем архитектурном митинге, где мы в частности обсуждали этот вопрос приняли решение:
В целом Вы isxam все правильно написали.
Magento отказалась от наследования DTO классов от Magento\Framework\Api\AbstractExtensibleObject, и сейчас новый код, в частности новые модули Inventory, используют наследование от Magento\Framework\Model\AbstractExtensibleModel.
Основную неразбериху, думаю вызвало то, что класс AbstractExtensibleObject помечен как `@api`, в то время как AbstractExtensibleModel не имеет соответствующей пометки.
Вчера на внутреннем архитектурном митинге, где мы в частности обсуждали этот вопрос приняли решение:
- Добавить PHP аннотацию `@api` для AbstractExtensibleModel
- Добавить PHP аннотацию `@deprecated` для AbstractExtensibleObject и `@see` которая ссылается на AbstractExtensibleModel
По поводу пункта 3.
Вы тоже правы, что extension_attributes это не о персистенсе, более того на этом уровне сущность должна быть описана persistence-agnostic.
И у нас по прежнему есть описание типа «join» в XSD Schema — github.com/magento/magento2/blob/2.2-develop/lib/internal/Magento/Framework/Api/etc/extension_attributes.xsd#L48-L55
но по факту вы не найдете его использования в модулях Magento, только в тестах.
Этот механизм, который назывался Join Directives был обьявлен как deprecated из-за причин описанных Вами и его поддержка остается только по причинам Backward Compatibility, поэтому сейчас обязанности по сохранению и извлечению атрибута возложены на программиста, зачастую это делается с помощью механизма плагинизации, например сервиса Repository::save($entity).
Более элегантное решение с точки зрения описания Entity, а также два типа декларации: persistence-agnostic высокоуровневой декларации, и низкоуровневой декларации, которая декларативно опишет загрузку данных (для ускорения производительности, так как сейчас с этим есть определенные пробелемы, так как дополнительные атрибуты хранятся в отдельных таблицах и нужно сохранять и загружать их отдельными запросами) появятся вместе с новым ORM в Magento
Вы тоже правы, что extension_attributes это не о персистенсе, более того на этом уровне сущность должна быть описана persistence-agnostic.
И у нас по прежнему есть описание типа «join» в XSD Schema — github.com/magento/magento2/blob/2.2-develop/lib/internal/Magento/Framework/Api/etc/extension_attributes.xsd#L48-L55
но по факту вы не найдете его использования в модулях Magento, только в тестах.
Этот механизм, который назывался Join Directives был обьявлен как deprecated из-за причин описанных Вами и его поддержка остается только по причинам Backward Compatibility, поэтому сейчас обязанности по сохранению и извлечению атрибута возложены на программиста, зачастую это делается с помощью механизма плагинизации, например сервиса Repository::save($entity).
Более элегантное решение с точки зрения описания Entity, а также два типа декларации: persistence-agnostic высокоуровневой декларации, и низкоуровневой декларации, которая декларативно опишет загрузку данных (для ускорения производительности, так как сейчас с этим есть определенные пробелемы, так как дополнительные атрибуты хранятся в отдельных таблицах и нужно сохранять и загружать их отдельными запросами) появятся вместе с новым ORM в Magento
Спасибо за развернутый ответ.
«новый ORM» это будет развитие \Magento\Framework\EntityManager\EntityManager?
В какой версии предполагается релиз этого функционала?
«новый ORM» это будет развитие \Magento\Framework\EntityManager\EntityManager?
В какой версии предполагается релиз этого функционала?
нет, это будет новый Entity Manager, мы добавили для старого \Magento\Framework\EntityManager\EntityManager такой комментарий в коде: github.com/magento/magento2/blob/2.2-develop/lib/internal/Magento/Framework/EntityManager/EntityManager.php#L15-L24
Основная причина отказаться от него — неэффективная работа с экстеншен атрибутами, работа с разными хранилищами данных, отсутствие эффективного механизма Query API.
>В какой версии предполагается релиз этого функционала?
Какие-то части функционала нового ORM мы уже зарелизим в 2.3.*
например декларативную схему — community.magento.com/t5/Magento-DevBlog/A-Declarative-Approach-for-Database-Schema-Upgrades/ba-p/70763
которая уже есть в 2.3-alpha
но полность функционал нового ORM должен быть доступен в версии 2.4
Основная причина отказаться от него — неэффективная работа с экстеншен атрибутами, работа с разными хранилищами данных, отсутствие эффективного механизма Query API.
>В какой версии предполагается релиз этого функционала?
Какие-то части функционала нового ORM мы уже зарелизим в 2.3.*
например декларативную схему — community.magento.com/t5/Magento-DevBlog/A-Declarative-Approach-for-Database-Schema-Upgrades/ba-p/70763
которая уже есть в 2.3-alpha
но полность функционал нового ORM должен быть доступен в версии 2.4
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Magento 2 REST API на примере простого модуля