4

Recently I've went through the "Fundamentals of Magento 2 development" course and there was such statement that we SHOULD NOT use functions from other modules that are not defined in the API interfaces for example we should not rely on \Magento\Framework\Model\AbstractModel save() method, because it can be removed in feature releases.

Ok, fine by me, but going this way we should not use, for instance, the load() function from \Magento\Framework\Model\ResourceModel\Db\AbstractDb right? Yet, it's recommended to use it in the same course. Can anyone point me in right direction?

Improve this question
1

2 Answers 2

Reset to default
6

Not using any methods not in the API interfaces is an ideal that is just not possible yet, because the service contracts are far from complete, and also sometimes you need more flexibility. The core violates this principle all over the place.

It's good to try using the interfaces first, but if it's not possible in a sensible way, be pragmatic about it (Remember that SHOULD NOT does not mean MUST NOT).

Regarding load(), see also:

Improve this answer
2
  • Thanks for the answer, I suspected that it will be this way, but wanted to confirm it. As for the load(), I was talking about ResourceModel function, not the Model one. I was just curious, according to the course I should not use load() on Model because it's not in the API but it's ok to use load() on ResourceModel which also is not in the API (sic!). Over a year after the official release... Anyway thanks!
    – Sebastian
    Commented Feb 23, 2017 at 17:42
  • Oh, I missed that point in the question. It would be interesting to know in which context the resource model was recommended. Probably for own models, because this is still how it works internally. But using resource models of other modules should(!) be avoided
    – Fabian Schmengler
    Commented Feb 23, 2017 at 19:17
3

Regarding AbstractModel and save/load methods. Magento doesn't recommend to use them, because these methods violate Single Responsibility principle (S from SOLID). Entity/Domain Model which destiny is to be responsible for some business operation shouldn't be responsible for self-retrieval and saving from/into the data storage. These methods are marked @deprecated in the codebase https://github.com/magento/magento2/blob/develop/lib/internal/Magento/Framework/Model/AbstractModel.php#L633 https://github.com/magento/magento2/blob/develop/lib/internal/Magento/Framework/Model/AbstractModel.php#L526

We expect that Entity should be Extracted with the help of Repository API. Which implementation uses Entity Manager or successor of ResourceModel under the hood.

In general, Magento recommends to use interfaces/classes marked with PHP Doc @api, which means that we consider these entities as a part of module's API contract. For now the coverage of entities in a codebase with @api annotation is not full. So, we can't say that it's enough to use just @api to proceed with all possible business operations (usage/extension/customization) for successful integration with Magento modules. That's why Magento considers all the code as public APIs now, and apply Backward Compatibility policy for the whole codebase with each release, to protect 3rd party extensions from being broken after update to new Magento version.

That's why we are going to inspect how 3rd party extensions use Magento modules (what Magento entities being used which are not marked as @api) and add @api annotation to all those entities, if there is no existing valid API which should be used instead. As soon as we make this demarcation, we would start to consider code which not marked as @api as Private implementation. Thus we will modify it without applying Backward Compatibility policy. All the @api entities will follow SemVer.

Improve this answer
1
  • Thanks! Could you also clarify something else for me? - will the core be refactored to use separate classes for data entities (like the customer model right now) or it isn't decided yet? - I assume that it is safe to use such functions as hasDataChangedFor() on AbstractModel for now, but what would you recommend, as this function is not a part of API, create in my module some business API class that will provide such function? - is the entity manager safe to use? I've came across some info that it's still in development, the info was old but still couldn't find any new
    – Sebastian
    Commented Feb 27, 2017 at 8:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.