Magento 2: Różnica między modelami a modelami danych

Wiem, że Magento 2 wprowadziło modele danych jako część architektury umowy serwisowej. Modele danych zwykle implementują interfejsy zdefiniowane w Api / Data / modułu.

Ale wydaje się, że Magento zachowało również stare modele.

Weźmy przykład do klienta-modułu.

• Interfejs modelu danych zdefiniowany w Api / Data / CustomerInterface.php
• Powyższy interfejs jest zaimplementowany w Model / Data / Customer.php
• Model danych ma wszystkie funkcje pobierania i ustawiania zmiennych klienta, zgodnie z oczekiwaniami
• Oprócz powyższego istnieje również Model / Customer.php. To także ma funkcję gettera i setera. To bardziej przypomina model Magento 1, który łączy się z ResourceModel (Model / ResourceModel / Customer.php)
• W Model / ResourceModel / CustomerRepository.php różne funkcje zbierają dane z modelu Magnento 1, przesyłają je do modelu danych, a następnie zwracają model danych.

Dlaczego potrzebny jest stary model? Dlaczego model danych nie może połączyć się bezpośrednio z ResourceModel?

Moje wyjaśnienie:

Bardzo trudno jest zrozumieć różnicę między modelem a modelem danych. Jeśli muszę powiedzieć w kilku słowach, mogę powiedzieć, że model reprezentuje silnik, a model danych reprezentuje jego informacje .

W przykładzie z jednostki klienta, można zobaczyć na przykład w jaki sposób authenticatelub validatePasswordsą przechowywane w modelu klienta, ponieważ są one częścią silnika i oni nie będą bezpośrednio obsługiwać informacji. Z drugiej strony, metody takie jak getExtensionAttributes, ponieważ obsługa części informacji jest przechowywana w modelu danych.

Myślę, że jest to po prostu lepsza obsługa projektów, podobnie jak podział na modele i modele zasobów, możesz zapytać, dlaczego ich potrzebujesz.

Dlaczego ich potrzebujesz:

Jeśli chcesz ujawnić informacje o kliencie (na przykład) za pomocą interfejsu API, potrzebujesz interfejsu ( \Magento\Customer\Api\Data\CustomerInterface) z modułami pobierającymi definiującymi wszystkie atrybuty Twojej jednostki, a jeśli masz inną metodę pobierającą nie reprezentującą informacji, którą chcesz ujawnić (np .: getRandomConfirmationKey), masz problem!

Właśnie dlatego w moim przykładzie getRandomConfirmationKeyjest częścią modelu ( \Magento\Customer\Model\Customer), podczas gdy getFirstnamejest częścią modelu danych.

Szybką zasadą może być:

• Jeśli twoja metoda reprezentuje kolumnę tabeli, atrybut lub informację o obiekcie dowolnego rodzaju, powinna przejść do modelu danych .
• Jeśli twoja metoda jest „działaniem” na informacje, obsługuje informacje lub deklarujesz je w pliku webapi.xml , powinna to być metoda modelowa .

POCZTA:

W kilku słowach: rozważ model danych prawie jako DTO.

Dodając do odpowiedzi @ Phoenix128_RiccardoT, warto zauważyć, że repozytoria (tj. MagentoCms\Api\BlockRepositoryLub Magento\Customer\Api\CustomerRepositoryInterface) również oczekują, że dostarczysz model danych, a nie zwykły. Modele danych są warstwą abstrakcji w porównaniu ze standardowymi modelami, która udostępnia tylko dane dostarczone przez jednostkę. Wszystkie „działania” dotyczące tych danych są przenoszone gdzie indziej.

Wygląda trochę jak idea encji w Symfony2 i Symfony3, gdzie encje zawierają tylko dane, a każda manipulacja danymi odbywa się w menedżerze encji. Wierzę, że w Magento2 rolę tę powierzono repozytoriom.

Stare modele są nadal z nami, ponieważ sposób, w jaki opracowano Magento2. Najwyraźniej nie zaczęli od pustego pliku index.php, ale ponownie użyli kodu z M1. Gdy spojrzeć na standardowych metod modelowych ( load(), save(), i delete()) wszystkie są oznaczone deprecated. Dzieje się tak, ponieważ to zadanie jest przenoszone do repozytoriów (oczywiście w niektórych przypadkach całe repozytorium obecnie wywołuje tę zwykłą save()metodę modelową , ale droga wydaje mi się jasna).

Modele zawierają logikę biznesową niezależną od pamięci, nie wiedzą o silnikach baz danych ani instancjach, w Magento 2 Modele danych to Obiekty Transferu Danych (DTO), implementacja specyficznych interfejsów DTO (model danych) dla modeli Magento CRUD (model ) określa, które metody klas są dostępne za pośrednictwem interfejsu API Magento WebAPI.

Model/Data/Customer.phpokreśla, które metody są dostępne dla interfejsu API, podczas gdy Model/Customer.phpma starszą implementację niestandardowych programów pobierających i ustawiających typu Magento 1 dostępnych dla operacji innych niż API.

Model/ResourceModel/CustomerRepository.php jest częścią nowej funkcji wprowadzonej w Magento 2 - Umowy serwisowe, współpracuje z kombinacją DTO (modele danych).

Ponieważ wiemy, że Magento ORM składa się z modeli, modeli zasobów i kolekcji i zależy od bazy danych, celem umowy serwisowej jest ukrycie logiki pamięci, aby klient podłączony do repozytorium (umowa serwisowa) nie dbał o pamięć docelową silnik.