Magento 2: Difference between Models and Data Models

Question

I'm aware that Magento 2 introduced data models as part of the service contract architecture. Data models usually implement interfaces defined in Api/Data/ of a module.

But, Magento seems to have retained the old models too.

Let's take an example to module-customer.

• Data model interface defined in Api/Data/CustomerInterface.php
• The above interface is implemented in Model/Data/Customer.php
• The data model has all the getter and setter function for the customer variables, as one would expect
• In addition to the above there is also a Model/Customer.php. This too has getter and setter function. This is more like a Magento 1 model that connects to the ResourceModel (Model/ResourceModel/Customer.php)
• In Model/ResourceModel/CustomerRepository.php, various function collect data from the Magnento 1 model, transfer them to the data model, and then return the data model.

Why does one need the old model? Why can't the data model directly connect with the ResourceModel?

Answer 1

My explaination:

It is very difficult to understand the difference between a model and a data model. If I have to say in few words I could say that a model represents the engine and a data model represents its information.

In your example, with the customer entity, you can see for example how the method authenticate or validatePassword are kept in customer model since they are part of the engine and they are not going to directly handle information. On the other side, methods like getExtensionAttributes, since handling pieces of information are kept in the data model.

I think this is just a better project handling, just like the division between models and resource models, you could ask why you need them as well.

Why you need them:

If you want to expose customer information (for example) using API, you will need an interface (\Magento\Customer\Api\Data\CustomerInterface) with getters defining all the attributes of your entity, and if you have any other getter method not representing an information you want to expose (e.g.: getRandomConfirmationKey), you have a problem!

Thi is why, in my example, getRandomConfirmationKey is part of the model (\Magento\Customer\Model\Customer), while getFirstname is part of the data model.

A quick rule could be:

• If your method represents a table column, an attribute or an entity information of any kind, then should go into data model.
• If your method is an "action" on the information, it handles the information or you declare it in webapi.xml, then it should be a model method.

POST:

In few words: consider a data model almost as a DTO.

Answer 2

Adding to @Phoenix128_RiccardoT answer, worth to notice is that repositories (ie. MagentoCms\Api\BlockRepository or Magento\Customer\Api\CustomerRepositoryInterface) also expects that you will provide data model and not regular one. Data models are an abstraction layer over standard models that exposes only data provided by the entity. All "actions" over this data is moved elsewhere.

It looks a little bit like the idea of entity in Symfony2 and Symfony3 where entities contains only data and any data manipulation is taking place in entity manager. In Magento2 this role, I believe, was given to repositories.

Old models are still with us because they way magento2 was developed. They evidently didn't start from blank index.php but reused some code from M1. When you take a look at standard model methods (load(), save(), and delete()) all are marked as deprecated. This is because that job is moved to repositories (granted that in some cases all the repository do now is calling this regular model save() method but the road seems clear to me).

Answer 3

Models encapsulate the storage independent business logic, they don't know about the database engines or instances, in Magento 2 Data Models are Data Transfer Objects (DTOs), implementation of the DTO (data model) specific interfaces for Magento CRUD models (the model) determines which class methods are available via the Magento WebAPI.

Model/Data/Customer.php determines which methods are available for the API whereas Model/Customer.php has legacy Magento 1 type implementation of custom getters and setters available for non API operations.

Model/ResourceModel/CustomerRepository.php is part of a new feature introduced in Magento 2 - Service Contracts, it works with the combination of DTO (Data Models).

As we know that Magento ORM consists of the Models, Resource Models and Collections and depends on Database, the purpose of a Service Contract is to hide the storage logic so a client connected to Repository (Service Contract) doesn't care about the target storage engine.