Magento 2: Diferença entre Modelos e Modelos de Dados

Estou ciente de que o Magento 2 introduziu modelos de dados como parte da arquitetura do contrato de serviço. Os modelos de dados geralmente implementam interfaces definidas em Api / Data / de um módulo.

Mas, Magento parece ter mantido os modelos antigos também.

Vamos dar um exemplo ao módulo-cliente.

• Interface do modelo de dados definida em Api / Data / CustomerInterface.php
• A interface acima é implementada em Model / Data / Customer.php
• O modelo de dados possui todas as funções getter e setter para as variáveis ​​do cliente, como seria de esperar
• Além do acima, também há um Model / Customer.php. Isso também tem a função getter e setter. É mais como um modelo Magento 1 que se conecta ao ResourceModel (Model / ResourceModel / Customer.php)
• Em Model / ResourceModel / CustomerRepository.php, várias funções coletam dados do modelo Magnento 1, transferem-nos para o modelo de dados e retornam o modelo de dados.

Por que alguém precisa do modelo antigo? Por que o modelo de dados não pode se conectar diretamente ao ResourceModel?

Minha explicação:

É muito difícil entender a diferença entre um modelo e um modelo de dados. Se preciso dizer em poucas palavras, posso dizer que um modelo representa o mecanismo e um modelo de dados representa suas informações .

No seu exemplo, com a entidade cliente, é possível ver, por exemplo, como o método authenticateou validatePasswordé mantido no modelo do cliente, pois eles fazem parte do mecanismo e não tratam diretamente as informações. Por outro lado, métodos como getExtensionAttributes, desde o manuseio de informações, são mantidos no modelo de dados.

Acho que esse é apenas um tratamento melhor do projeto, assim como a divisão entre modelos e modelos de recursos, você pode perguntar por que precisa deles também.

Por que você precisa deles:

Se você deseja expor as informações do cliente (por exemplo) usando a API, precisará de uma interface ( \Magento\Customer\Api\Data\CustomerInterface) com getters definindo todos os atributos da sua entidade e se tiver algum outro método getter que não represente as informações que deseja expor (por exemplo: getRandomConfirmationKey), você tem um problema!

É por isso que, no meu exemplo, getRandomConfirmationKeyfaz parte do model ( \Magento\Customer\Model\Customer), enquanto getFirstnamefaz parte do modelo de dados.

Uma regra rápida pode ser:

• Se seu método representa uma coluna da tabela, um atributo ou uma informação de entidade de qualquer tipo, você deve entrar no modelo de dados .
• Se seu método for uma "ação" nas informações, ele manipula as informações ou você as declara em webapi.xml , então deve ser um método de modelo .

POSTAR:

Em poucas palavras: considere um modelo de dados quase como um DTO.

Acrescentando à resposta do @ Phoenix128_RiccardoT, vale notar que os repositórios (ie. MagentoCms\Api\BlockRepositoryOu Magento\Customer\Api\CustomerRepositoryInterface) também esperam que você forneça um modelo de dados e não um modelo regular. Modelos de dados são uma camada de abstração sobre modelos padrão que expõe apenas os dados fornecidos pela entidade. Todas as "ações" sobre esses dados são movidas para outro lugar.

Parece um pouco com a idéia de entidade no Symfony2 e Symfony3, onde as entidades contêm apenas dados e qualquer manipulação de dados está ocorrendo no gerenciador de entidades. No Magento2 esse papel, acredito, foi atribuído aos repositórios.

Modelos antigos ainda estão conosco porque eles desenvolveram o magento2. Evidentemente, eles não começaram do index.php em branco, mas reutilizaram algum código do M1. Quando você dar uma olhada em métodos de modelo padrão ( load(), save()e delete()) todos são marcados como deprecated. Isso ocorre porque esse trabalho é movido para repositórios (desde que, em alguns casos, todo o repositório esteja chamando esse save()método de modelo regular , mas a estrada me pareça clara).

Os modelos encapsulam a lógica de negócios independente de armazenamento, eles não sabem sobre os mecanismos ou instâncias de banco de dados. No Magento 2 Data Models são Data Transfer Objects (DTOs), implementação das interfaces específicas do DTO (modelo de dados) para os modelos Magento CRUD (o modelo ) determina quais métodos de classe estão disponíveis no Magento WebAPI.

Model/Data/Customer.phpdetermina quais métodos estão disponíveis para a API, enquanto a Model/Customer.phpimplementação herdada do tipo Magento 1 de getters e setters personalizados está disponível para operações que não são da API.

Model/ResourceModel/CustomerRepository.php faz parte de um novo recurso introduzido no Magento 2 - Contratos de Serviço, funciona com a combinação de DTO (Modelos de Dados).

Como sabemos que o Magento ORM consiste em modelos, modelos de recursos e coleções e depende do banco de dados, o objetivo de um contrato de serviço é ocultar a lógica de armazenamento para que um cliente conectado ao repositório (contrato de serviço) não se importe com o armazenamento de destino motor.