Magento 2: differenza tra modelli e modelli di dati

Sono consapevole che Magento 2 ha introdotto modelli di dati come parte dell'architettura del contratto di servizio. I modelli di dati di solito implementano interfacce definite in Api / Dati / di un modulo.

Ma Magento sembra aver mantenuto anche i vecchi modelli.

Facciamo un esempio per modulo-cliente.

• Interfaccia del modello di dati definita in Api / Data / CustomerInterface.php
• L'interfaccia sopra è implementata in Model / Data / Customer.php
• Il modello di dati ha tutte le funzioni getter e setter per le variabili del cliente, come ci si aspetterebbe
• Oltre a quanto sopra c'è anche un Model / Customer.php. Anche questo ha funzione getter e setter. È più simile a un modello Magento 1 che si collega a ResourceModel (Model / ResourceModel / Customer.php)
• In Model / ResourceModel / CustomerRepository.php, varie funzioni raccolgono dati dal modello Magnento 1, li trasferiscono nel modello dati e quindi restituiscono il modello dati.

Perché è necessario il vecchio modello? Perché il modello di dati non può connettersi direttamente con ResourceModel?

La mia spiegazione:

È molto difficile comprendere la differenza tra un modello e un modello di dati. Se dovessi dire in poche parole, potrei dire che un modello rappresenta il motore e un modello di dati rappresenta le sue informazioni .

Nel tuo esempio, con l'entità cliente, puoi vedere, ad esempio, come il metodo authenticateo validatePasswordsono conservati nel modello del cliente poiché fanno parte del motore e non gestiranno direttamente le informazioni. Dall'altro lato, metodi come getExtensionAttributes, poiché la gestione di informazioni sono mantenute nel modello di dati.

Penso che sia solo una migliore gestione del progetto, proprio come la divisione tra modelli e modelli di risorse, potresti chiederti perché ne hai bisogno anche tu.

Perché ne hai bisogno:

Se vuoi esporre le informazioni sui clienti (ad esempio) utilizzando l'API, avrai bisogno di un'interfaccia ( \Magento\Customer\Api\Data\CustomerInterface) con getter che definisca tutti gli attributi della tua entità, e se hai qualche altro metodo getter che non rappresenta un'informazione che vuoi esporre (es: getRandomConfirmationKey), hai un problema!

Questo è il motivo per cui, nel mio esempio, getRandomConfirmationKeyfa parte del modello ( \Magento\Customer\Model\Customer), mentre getFirstnamefa parte del modello di dati.

Una regola veloce potrebbe essere:

• Se il tuo metodo rappresenta una colonna di tabella, un attributo o un'entità informazioni di qualsiasi tipo, allora dovrebbe andare nel modello di dati .
• Se il tuo metodo è "un'azione" sulle informazioni, gestisce le informazioni o le dichiari in webapi.xml , quindi dovrebbe essere un metodo modello .

INVIARE:

In poche parole: considerare un modello di dati quasi come un DTO.

Aggiungendo alla risposta @ Phoenix128_RiccardoT, vale la pena notare che i repository (es. MagentoCms\Api\BlockRepositoryO Magento\Customer\Api\CustomerRepositoryInterface) si aspettano anche che tu fornisca un modello di dati e non uno regolare. I modelli di dati sono un livello di astrazione rispetto ai modelli standard che espongono solo i dati forniti dall'entità. Tutte le "azioni" su questi dati vengono spostate altrove.

Assomiglia un po 'all'idea di entità in Symfony2 e Symfony3 in cui le entità contengono solo dati e qualsiasi manipolazione dei dati è in atto nel gestore entità. In Magento2 questo ruolo, credo, è stato assegnato ai repository.

I vecchi modelli sono ancora con noi perché hanno sviluppato magento2. Evidentemente non sono partiti da index.php vuoto ma hanno riutilizzato del codice da M1. Quando si dà un'occhiata a metodi del modello standard ( load(), save(), e delete()), tutti sono contrassegnati come deprecated. Questo perché quel lavoro viene spostato nei repository (ammesso che in alcuni casi tutto il repository faccia ora questo save()metodo modello normale ma la strada mi sembra chiara).

I modelli incapsulano la logica di business indipendente dallo storage, non conoscono i motori o le istanze del database, in Magento 2 i modelli di dati sono Data Transfer Objects (DTO), l'implementazione delle interfacce specifiche DTO (modello di dati) per i modelli Magento CRUD (il modello ) determina quali metodi di classe sono disponibili tramite Magento WebAPI.

Model/Data/Customer.phpdetermina quali metodi sono disponibili per l'API, mentre Model/Customer.phpha un'implementazione legacy di tipo Magento 1 di getter e setter personalizzati disponibili per operazioni non API.

Model/ResourceModel/CustomerRepository.php fa parte di una nuova funzionalità introdotta in Magento 2 - Contratti di assistenza, funziona con la combinazione di DTO (modelli di dati).

Poiché sappiamo che Magento ORM è costituito da modelli, modelli di risorse e raccolte e dipende dal database, lo scopo di un contratto di servizio è nascondere la logica di archiviazione in modo che un client collegato al repository (contratto di servizio) non si preoccupi dell'archiviazione di destinazione motore.