Magento 2: to use or not to use the ObjectManager directly?

Ok, so yesterday we had a big talk with other people from the Magento community regarding the direct use of the ObjectManager in classes/templates.

I'm already aware of the reasons why we shouldn't use the ObjectManager directly, quoting Alan Kent :

There are several reasons. The code will work, but it is best practice to not reference the ObjectManager class directly.

Because we say so! ;-) (better expressed as consistent code is good code)

The code could be used with a different dependency injection framework in the future

Testing is easier - you pass in mock arguments for the required class, without having to provide a mock ObjectManager

It keeps dependencies clearer - it is obvious what the code depends on via constructor list, rather than having dependencies hidden in the middle of the code

It encourages programmers to think about concepts like encapsulation and modularization better - if the constructor gets big, maybe it is a sign the code needs refactoring

From what I've seen in StackExchange, a lot of people tend to go for the easy/short/not recommended solution for example something like this:

<?php 
//Get Object Manager Instance
$objectManager = \Magento\Framework\App\ObjectManager::getInstance();

//Load product by product id
$product = $objectManager->create('Magento\Catalog\Model\Product')->load($id);

Instead of going through the painful but recommended process of:

creating a module
declaring preferences
inject dependencies
declare a public method

However, and here comes the dilemma, Magento 2 core files often call the ObjectManager directly. A quick example can be found here: https://github.com/magento/magento2/blob/develop/app/code/Magento/GoogleOptimizer/Block/Adminhtml/Form.php#L57

So here are my questions:

Why is Magento doing what they recommend us not to do ? Does that mean there are some cases where we should use the ObjectManager directly? If so, what are those cases?
What are the consequences of using the ObjectManager directly?

Raphael at Digital Pianism

Posted 2016-05-26T11:19:29.777

Reputation: 47 283

at many places magento core team used directly Objectmanager concepts, then why we cant use it? – Rakesh Jesadiya – 2016-05-26T11:24:40.167

@Rakesh that's exactly my question ;) as we talked yesterday, I got concerned about that problem, I reckon this need clarification. – Raphael at Digital Pianism – 2016-05-26T11:25:42.827

Check this out: http://magento.stackexchange.com/q/28617/146

– Marius – 2016-05-26T11:29:52.620

Relevant link: https://mwop.net/blog/2016-04-26-on-locators.html. The relevant bit of it would be The intent of zend-servicemanager is for use as an Inversion of Control container. It was never intended as a general purpose service locator [...]. Which it applies to M2, too. Also check the There are valid use cases section, which, again, applies here, too.

– nevvermind – 2016-05-26T12:29:10.627

Being scared of breaking things vs direct use of the ObjectManager is worse than I thought https://github.com/magento/magento2/commit/90f4decc16357dddfc91366d8b37f2668be18631

– Kristof at Fooman – 2016-05-27T14:59:01.900

3There was some period of M2 development when OM was already there, but whole magento was not yet changed to use constructor injection. At that point many people replaced Mage::getSingleton() with ObjectManager::getInstance()->get(). Most of such usages were introduced at that period. Later all Mage::getSingleton() calls were replaced with constructor injection by a tool, but tool did not recognized ObjectManager::getInstance(), so it did not replace it with constructor injection. – Anton Kril – 2016-10-06T11:03:14.707

Possible duplicate of Magento 2 Helper instance

– Teja bhagavan Kollepara – 2017-02-20T12:08:00.090

2@TejabhagavanKollepara did you read both questions ? There are similar but far from being duplicate from each other – Raphael at Digital Pianism – 2017-02-20T12:15:53.777

" if the constructor gets big, maybe it is a sign the code needs refactoring".. OK but what should be do when we have to extends a native MG2 class (it happens sometimes) which already have a huge constructo? – enrico69 – 2017-09-29T16:06:53.530

Answers

You should not use the ObjectManager directly!

Exception from the rule are:

in static magic methods like __wakeup, serialize, etc
in case you should make backward compatibility of constructor
in global scope, like in fixtures of integration test.
in class that needs only for creation of object like factory, proxy , etc

KAndy

Posted 2016-05-26T11:19:29.777

Reputation: 13 549

I know I should never use it directly but why is Magento doing it ? ^^ – Raphael at Digital Pianism – 2016-05-26T11:41:54.680

2in your example is for backward compatibility – KAndy – 2016-05-26T11:42:58.170

Are those always flagged as @deprecated ? – Raphael at Digital Pianism – 2016-05-26T11:54:13.970

What about this one: https://github.com/magento/magento2/blob/develop/app/code/Magento/GoogleOptimizer/Block/Adminhtml/Form.php#L57 ?

– Raphael at Digital Pianism – 2016-05-26T12:02:47.843

Not allways, but its private, so we can remove its code at any time – KAndy – 2016-05-26T12:04:11.557

@RaphaelatDigitalPianism, it's hard to believe but Magento developing by humans and they can also make mistakes ;) – KAndy – 2016-05-26T20:00:42.507

3oh yeah mate I know it is just confusing. Maybe they should have said "don't do it but be aware that we have probably left some mistakes here and there" ;) – Raphael at Digital Pianism – 2016-05-26T20:23:43.593

What if you have class of 10 functions and ONLY 1 function requires specific model? Wouldn't be redundant (from performance view) to load model through constructor injection for each of 10 functions while we could load it using object manager only inside 1 single function? – JohnyFree – 2016-07-19T15:38:51.640

if you have the class of 10 functions, you already have a problem and optional dependency, not a big deal. In any case, you may use proxy for optional dependencies – KAndy – 2016-07-19T16:03:49.110

@KAndy what if you want to use Custom Variables (Magento\Variable\Model\Variable) in phtml templates? Since a custom variable could potentially be used in any phtml file, it would be impossible to know ahead of time which core file to override for DI, so in this case what would be the best practice? – 10basetom – 2016-10-06T02:43:53.090

what about injecting the object manager into a helper which can be used on any template? – minlare – 2016-12-07T11:18:30.260

Magento do not recommends use helpers, so... – KAndy – 2016-12-07T12:01:39.670

You might need to use object manager to implement refection. – Kervin Ramen – 2017-05-12T11:39:10.340

Another exception to this is soft dependencies. You can't DI the class in because it will throw an error if the class doesn't exist (which is totally fine if you have a soft dependency) – Nathan Merrill – 2017-11-21T21:15:57.540

You should never use \Magento\Framework\App\ObjectManager::getInstance().
It defeats the purpose of dependency injection. We're back at Mage::getModel().
Object manager should be used only in factories and then as injected in a constructor.

The advantage of using this is less code to write. But this does not make it OK.
The fact that this is still used in the core, is because it didn't get refactored yet. I hope it will be.

Marius

Posted 2016-05-26T11:19:29.777

Reputation: 150 497

3So we both agree that Magento code is doing it wrong right ? – Raphael at Digital Pianism – 2016-05-26T11:41:20.677

7right. they are wrong :). – Marius – 2016-05-26T11:43:51.440

I don't think they're using wrong. They're using it when necessary: when dynamic resolving is needed (plugins, especially) and when keeping BC on immediately-deprecated methods. – nevvermind – 2016-05-26T12:32:41.673

@nevvermind see the github link in my question, it definitely doesn't sound right to me to use OM in this case – Raphael at Digital Pianism – 2016-05-26T13:20:33.433

Maybe that particular bit should be refactored, but, in general, I don't see a problem directly using the OM to instantiate classes which you don't know beforehand (aka dynamic). How would you do that without using the OM? – nevvermind – 2016-05-26T14:56:01.273

2@nevvermind Using a factory. You use di.xml to create a key => class name map and inject that map in to constructor of the factory and use the factory to instantiate the class through objectmanager – Marius – 2016-05-26T15:07:08.827

That's good for small maps, but when it gets bigger, you'll find that that array is getting harder to maintain and it's starting to actually duplicate an aspect of the OM: a map of classes/objects. It becomes a whitelist, filtering out possible valid cases. I dislike it when people use the OM directly for various things, too, but I'm also trying to be flexible. Asking M2 never to use the OM in their models is a bit rigid, in my opinion. – nevvermind – 2016-05-26T15:28:57.660

@nevvermind But a Magento employee's opinion outranks your opinion. You have an answer above from KAndy that states in bold letter "you should not use the object manager directly": http://magento.stackexchange.com/a/117103/146 I guess that kind of clears the fog on the issue.

– Marius – 2016-05-26T15:31:27.073

Not sure about the criteria used in outranking someone else's opinion, but yeah, I guess so. ¯_(ツ)_/¯ LE: I think he's saying "Don't use eval in PHP". – nevvermind – 2016-05-26T15:34:21.930

there are various reasons why you should not use it directly. You can google it :P – David Verholen – 2016-05-26T17:40:33.943

I'm currently using \Magento\Framework\App\ObjectManager::getInstance() to output custom variables in phtml templates since Magento 2 doesn't seem to have a built-in method to do this. – 10basetom – 2017-03-08T09:42:21.403

@10basetom. This is wrong. your templates should not contain logic. Move the logic part to a block class and use that one. – Marius – 2017-03-08T09:45:11.750

@Marius thanks for the advice. However, if I'm getting custom variables in multiple modules (e.g., Magento_Catalog, Magento_Checkout), would I have to override Block class for each module? – 10basetom – 2017-03-10T01:50:01.827

@Marius, What if I want to use a custom table model in an event observer? How can I get the collection in an event? – Magento Learner – 2017-09-12T11:09:22.710

Thank you for your advice, just a quick query what be your advice on getting the names of my categories if I should never use \Magento\Framework\App\ObjectManager::getInstance() ? Thanks – John – 2018-02-01T08:49:58.993

@JohnC There are core classes that do this (not sure which ones). You should use in one of your blocks that class, inject it in the constructor and retrieve the names. Maybe you should ask a separate question about this. – Marius – 2018-02-01T08:54:08.810

Thank you Marius, will do! – John – 2018-02-01T08:55:07.170

So why does M2 sometimes access object manager directly when we recommend against it?

Brutal answer: M2 is a port of M1 - not a complete rewrite. So don't assume that all the M2 code is perfectly ported yet (unfortunately). Just because you find something in the M2 code base, that does not mean "its the best way to do it". Sometimes it is just "we have not got around to fixing it yet".

Less brutal: As per other responses, sometimes you MUST use it as there is no alternative. Other times it might be for backwards compatibility reasons. And framework code sometimes makes sense using it directly, because it is framework code. But if I had to guess without looking at code, many really should be fixed but it has not been high enough priority to do so yet.

Just remember the good parenting advice: "Kids, do what I say, not what I do!"

Alan Kent

Posted 2016-05-26T11:19:29.777

Reputation: 2 848

2excellent quote:Kids, do what I say, not what I do! – sivakumar – 2016-06-01T01:16:55.920

That's not how it works kiddo – Ansyori – 2017-06-01T07:36:47.117

Why is Magento doing what they recommend us not to do ? Does that mean there are some cases where we should use the ObjectManager directly ? If so, what those cases ?

Without knowing the full story here is my guess:

During the development of M2 the Magento team at some stage ran an automated script which replaced occurrences of Mage:getModel(), Mage::getSingleton(), $layout->createBlock(), etc. to use the ObjectManager.

Later refactoring should have fixed this to instead use proper dependency injection but there wasn't enough time / resources to convert all occurrences.

Also the Magento team lately seems to use this as an escape mechanism. Instead of breaking an existing implementation (by needing to change the constructor) they simply hide the new dependency via the ObjectManager. I can't say I agree with this approach - writing worse code to avoid a BC break.

What are the direct consequences of using the ObjectManager directly ?

I think your question already includes enough reasons. Generally it creates a hidden dependency, in other words the dependency is in the implementation details and not visible from the constructor alone.

Kristof at Fooman

Posted 2016-05-26T11:19:29.777

Reputation: 9 528

It is ironic because had there done it properly before releasing to the public the BC wouldn't have been an issue at all – Robbie Averill – 2016-05-31T17:50:39.250

Should not use Object manager directly!! like

\Magento\Framework\App\ObjectManager::getInstance();

but if you are working with event or plugins you have to use direct.

but except that you should Inject Object Manager in Constructor first then you can use its object in your method

Preferred to use :

1) desclare private object:

private $_objectManager;

2) inject in constructor and initialize:

public function __construct(
    \Magento\Framework\ObjectManagerInterface $objectmanager
) {
    $this->_objectManager = $objectmanager;
}

Ronak Chauhan

Posted 2016-05-26T11:19:29.777

Reputation: 4 158

Is it a good practice to use it this way? – enrico69 – 2017-09-29T16:04:30.267

Yes, because magento doesn't allow to use direct objectManager, so you have to use this way! – Ronak Chauhan – 2017-09-29T17:23:09.873

One very important reason that developers are strongly discouraged from using the Object Manager directly is that direct use causes the extension not to be installable in compiled release mode.

So it breaks for your customers using release mode, including all customers on Magento Cloud.

The Marketplace L1 scans do not currently test that extensions can be installed correctly: they are merely static scans.

This means that the responsibility for testing that your extension will install lies with you, the developer.

It seems like a reasonably large proportion of developers do not test their extensions to see if they can be installed, so do not run into the issues posed by incorrect ObjectManager usage.

Dewi Morgan

Posted 2016-05-26T11:19:29.777

Reputation: 191