Magento 2 ObjectManager Use Cases

The biggest problem regarding ObjectManager in Magento 2 is that you can fully leverage the useful technology, but it is not recommended to do so. Although the direct use of the ObjectManager in classes/templates is possible (popular) and Magento 2 core files often call the ObjectManager directly, Alan Kent asks the community members not to do so. Below, you can find several reasons to avoid using ObjectManager in Magento 2 as well as a few exceptions.

According to Alan Kent, the first reason against using ObjectManager in Magento 2 is because the core team of developers asks not to do that. As creators of the platform, they know lots of nuances and just want to prevent you from future headaches.

As for more articulable reasons, they include some future changes that will be applied to the platform. For instance, a new dependency injection framework will be used for the code. By avoiding ObjectManager in Magento 2, you won’t face multiple issues caused by the improvement.

The second reason against ObjectManager in Magento 2 is testing. It becomes easier since it is not necessary to provide a mock ObjectManager passing in mock arguments for the required class.

There is also the third reason that will keep you away from ObjectManager. If you don’t use it, you keep dependencies clearer. It is much easier to understand the code dependencies by exploring the constructor list rather than looking for them somewhere in the middle of the code.

And avoiding ObjectManager is a great motivator for the better understanding of encapsulation and modularization. Every time you see that the constructor is huge, start code refactoring.

But what about the direct use of ObjectManager by core files of Magento 2? They rely on the technology really often, and you can find lots of examples on GitHub. And as a Magento 2 developer, you are asked to go through a painful batch of processes while creating a module. You have to declare preferences, inject dependencies, and declare a public method.

The community offers to eliminate the recommended routine by implemented the following approach:

It is easier and shorter but not recommended. And it is obvious that Magento is doing the same things but asks us not to do so.

The use of ObjectManager defeats the purpose of dependency injection. Therefore, you should only use the technology in factories injected in a constructor.

The core reason many people want to use ObjectManager is a smaller code, but it is not a better code. The technology is still used in the core because it didn’t get refactored. Thus, don’t use the ObjectManager directly. Of course, there are several exceptions.

First of all, you can fully leverage ObjectManager in static magic methods. This exception includes everything similar to __wakeup and serialize. Here, the Magento 2 ObjectManager won’t make your project worse.

The second exception is related to a backward compatibility. If it is necessary to create a backward compatibility of a constructor, feel free to leverage ObjectManager in Magento 2.

Global scope is the third exception. Think about fixtures of integration tests as of a good place for leveraging ObjectManager.

And the last way to use ObjectManager without any negative influence on the project is related to a class required for the creation of objects like factory or proxy.

We hope this article was useful. It is based on the StackExchange question by Raphael and answers by KAndy and Marius♦. For more useful articles, check out our Cookbook.