Magento 2: Різниця між моделями та моделями даних

Мені відомо, що Magento 2 представив моделі даних як частину архітектури контрактів на послуги. Моделі даних зазвичай реалізують інтерфейси, визначені в Api / Data / модуля.

Але, Magento, схоже, зберегли і старі моделі.

Візьмемо приклад для модуля-замовника.

• Інтерфейс моделі даних визначений в Api / Data / CustomerInterface.php
• Вищевказаний інтерфейс реалізований у Model / Data / Customer.php
• Модель даних має всі функції отримання та встановлення для змінних клієнтів, як можна було б очікувати
• На додаток до вищезазначеного також є Model / Customer.php. У цьому теж є функція геттера та сетера. Це більше схоже на модель Magento 1, яка підключається до ResourceModel (Model / ResourceModel / Customer.php)
• У Model / ResourceModel / CustomerRepository.php різні функції збирають дані з моделі Magnento 1, передають їх у модель даних, а потім повертають модель даних.

Для чого потрібна стара модель? Чому модель даних не може безпосередньо з'єднуватися з ResourceModel?

Моє пояснення:

Дуже важко зрозуміти різницю між моделлю та моделлю даних. Якщо мені доведеться сказати кількома словами, я можу сказати, що модель представляє двигун, а модель даних представляє його інформацію .

У вашому прикладі, з організацією-замовником, ви можете побачити, наприклад, як метод authenticateабо validatePasswordзберігаються в моделі клієнта, оскільки вони є частиною двигуна, і вони не збираються безпосередньо обробляти інформацію. З іншого боку, такі способи getExtensionAttributes, як обробка інформації, зберігаються в моделі даних.

Я думаю, що це просто краща робота з проектами, як і поділ між моделями та моделями ресурсів, ви можете запитати, навіщо вони вам також потрібні.

Для чого вони потрібні:

Якщо ви хочете розкрити інформацію про клієнтів (наприклад) за допомогою API, вам знадобиться інтерфейс ( \Magento\Customer\Api\Data\CustomerInterface) з геттерами, що визначають усі атрибути вашої організації, і якщо у вас є інший метод отримання, який не представляє інформацію, яку ви хочете викрити (наприклад: getRandomConfirmationKey), у вас проблема!

Тому, на моєму прикладі, getRandomConfirmationKeyє частиною моделі ( \Magento\Customer\Model\Customer), тоді як getFirstnameє частиною моделі даних.

Швидке правило може бути:

• Якщо ваш метод представляє стовпчик таблиці, атрибут або інформацію про сутність будь-якого типу, тоді слід перейти до моделі даних .
• Якщо ваш метод є "дією" на інформацію, він обробляє інформацію або ви заявляєте її в webapi.xml , тоді це повинен бути модельний метод.

POST:

Кілька слів: розгляньте модель даних майже як DTO.

Додавши до @ Phoenix128_RiccardoT відповідь, варто зазначити, що сховища (тобто MagentoCms\Api\BlockRepositoryабо Magento\Customer\Api\CustomerRepositoryInterface) також очікують, що ви надасте модель даних, а не звичайну. Моделі даних - це рівень абстрагування над стандартними моделями, який відкриває лише дані, що надаються сутністю. Усі "дії" над цими даними переміщуються в інше місце.

Це трохи схоже на ідею сутності в Symfony2 та Symfony3, де об'єкти містять лише дані, а будь-яка маніпуляція даними відбувається в менеджері сутностей. В Magento2 цю роль, я вважаю, відводили сховищам.

Старі моделі все ще з нами, тому що вони були розроблені magento2. Вони, очевидно, не починалися з пустого index.php, але повторно використовували деякий код з M1. Коли ви подивіться на стандартних модельних методів ( load(), save()і delete()) все позначені як deprecated. Це тому, що ця робота переміщується в сховища (за умови, що в деяких випадках зараз все сховище викликає цей звичайний save()метод моделі, але дорога мені здається зрозумілою).

Моделі інкапсулюють незалежну бізнес-логіку зберігання, вони не знають про двигуни бази даних або екземпляри, в Magento 2 Моделі даних - це об'єкти передачі даних (DTO), реалізація специфічних інтерфейсів DTO (модель даних) для моделей Magento CRUD (модель ) визначає, які методи класів доступні через Magento WebAPI.

Model/Data/Customer.phpвизначає, які способи доступні для API, тоді як Model/Customer.phpмає застарілу реалізацію типу Magento 1 користувацьких геттерів та сетерів, доступних для операцій, які не належать API.

Model/ResourceModel/CustomerRepository.php є частиною нової функції, представленої в Magento 2 - Контракти на обслуговування, вона працює з комбінацією DTO (Data Models).

Оскільки ми знаємо, що Magento ORM складається з моделей, моделей ресурсів та колекцій і залежить від бази даних, метою сервісного контракту є приховування логіки зберігання, щоб клієнт, підключений до сховища (контракт на обслуговування), не піклувався про цільове сховище двигун.