Magento 2: używać lub nie używać bezpośrednio menedżera obiektów ObjectManager?

Ok, więc wczoraj rozmawialiśmy z innymi ludźmi ze społeczności Magento na temat bezpośredniego wykorzystania ObjectManagerklas / szablonów .

Jestem już świadomy powodów, dla których nie powinniśmy bezpośrednio używać ObjectManager, cytując Alana Kenta :

Jest kilka powodów. Kod będzie działał, ale najlepiej jest nie odwoływać się bezpośrednio do klasy ObjectManager.

• Ponieważ tak mówimy! ;-) (lepiej wyrażony jako spójny kod to dobry kod)
• W przyszłości kod może być używany z inną strukturą wstrzykiwania zależności
• Testowanie jest łatwiejsze - przekazujesz fałszywe argumenty dla wymaganej klasy, bez konieczności podawania próbnego menedżera obiektów ObjectManager
• Utrzymuje jaśniejsze zależności - oczywiste jest, od czego zależy kod za pośrednictwem listy konstruktorów, a nie ukrywanie zależności w środku kodu
• Zachęca programistów do lepszego myślenia o koncepcjach takich jak enkapsulacja i modularyzacja - jeśli konstruktor się powiększy, być może jest to znak, że kod wymaga refaktoryzacji

Z tego, co widziałem w StackExchange, wiele osób wybiera proste / krótkie / niezalecane rozwiązanie, na przykład coś takiego:

<?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);

Zamiast przechodzić przez bolesny, ale zalecany proces :

• tworzenie modułu
• deklarowanie preferencji
• wstrzykiwać zależności
• zadeklarować metodę publiczną

Jednak i tu pojawia się dylemat, podstawowe pliki Magento 2 często wywołują bezpośrednio ObjectManager . Szybki przykład można znaleźć tutaj: https://github.com/magento/magento2/blob/develop/app/code/Magento/GoogleOptimizer/Block/Adminhtml/Form.php#L57

Oto moje pytania:

• Dlaczego Magento robi to, czego od nas nie zaleca? Czy to oznacza, że istnieją przypadki, w których powinniśmy użyć ObjectManagerbezpośrednio ? Jeśli tak, jakie to są przypadki?
• Jakie są konsekwencje bezpośredniego korzystania z ObjectManager ?

Nie należy bezpośrednio używać ObjectManager!

Wyjątkiem od reguły są:

• w statycznych magicznych metod, takich jak __wakeup, serializeitp
• w przypadku, gdy powinieneś zrobić wsteczną kompatybilność konstruktora
• w zakresie globalnym, jak w urządzeniach testu integracji.
• w klasie, która potrzebuje tylko do tworzenia takich obiektów, jak fabryka, serwer proxy itp

Dlaczego więc M2 czasami czasami uzyskuje bezpośredni dostęp do menedżera obiektów, skoro odradzamy?

Brutalna odpowiedź: M2 to port M1 - nie jest to kompletne przepisanie. Nie zakładaj więc, że cały kod M2 jest jeszcze doskonale przeniesiony (niestety). To, że znajdziesz coś w bazie kodu M2, nie oznacza, że ​​„jest to najlepszy sposób na zrobienie tego”. Czasami jest to po prostu „jeszcze nie udało się tego naprawić”.

Mniej brutalny: tak jak w przypadku innych odpowiedzi, czasami MUSISZ go użyć, ponieważ nie ma alternatywy. Innym razem może to wynikać z kompatybilności wstecznej. A kod frameworka czasami ma sens z jego bezpośrednim użyciem, ponieważ jest to kod frameworka. Ale gdybym musiał zgadywać bez patrzenia na kod, wiele naprawdę powinno zostać naprawionych, ale nie był jeszcze wystarczająco wysoki priorytet, aby to zrobić.

Pamiętaj tylko o dobrych radach dla rodziców: „Dzieci, róbcie to, co mówię, a nie to, co robię!”

Nigdy nie powinieneś używać \Magento\Framework\App\ObjectManager::getInstance().
To przeczy celowi wstrzykiwania zależności. Wróciliśmy do Mage::getModel().
Menedżer obiektów powinien być używany tylko w fabrykach, a następnie wprowadzany do konstruktora.

Zaletą korzystania z tego jest mniej kodu do pisania. Ale to nie sprawia, że ​​jest OK.
Fakt, że jest on nadal używany w rdzeniu, ponieważ nie został jeszcze refaktoryzowany. Mam nadzieję, że będzie.

Dlaczego Magento robi to, czego od nas nie zaleca? Czy to oznacza, że ​​istnieją przypadki, w których powinniśmy bezpośrednio używać ObjectManager? Jeśli tak, jakie te przypadki?

Nie znając pełnej historii, zgaduję:

Podczas rozwoju M2 zespół Magento w pewnym momencie zabrakło zautomatyzowany skrypt, który zastąpił wystąpień Mage:getModel(), Mage::getSingleton(), $layout->createBlock()itp używać ObjectManager.

Później refaktoryzacja powinna była to naprawić, aby zamiast tego użyć właściwego wstrzykiwania zależności, ale nie było wystarczająco dużo czasu / zasobów, aby przekonwertować wszystkie wystąpienia.

Ostatnio zespół Magento wydaje się używać tego jako mechanizmu ucieczki. Zamiast przerywać istniejącą implementację (poprzez konieczność zmiany konstruktora), po prostu ukrywają nową zależność za pomocą ObjectManager. Nie mogę powiedzieć, że zgadzam się z tym podejściem - pisząc gorszy kod, aby uniknąć złamania BC.

Jakie są bezpośrednie konsekwencje bezpośredniego używania ObjectManager?

Myślę, że twoje pytanie zawiera już wystarczające powody. Generalnie tworzy ukrytą zależność, innymi słowy, zależność jest w szczegółach implementacji i nie jest widoczna dla samego konstruktora.

Nie należy używać bezpośrednio Menedżera obiektów!

Na przykład:

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

także jeśli pracujesz z obserwatorami zdarzeń lub wtyczkami, nigdy nie powinieneś używać go bezpośrednio.

Możesz użyć go w Fabrykach, ale oprócz tego, że najpierw powinieneś wstrzyknąć Menedżer obiektów do Konstruktora, możesz użyć jego obiektu w swojej metodzie

Preferowane użycie:

1) zadeklaruj obiekt prywatny:

private $_objectManager;

2) wstrzyknąć konstruktor i zainicjować:

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

3) użyj w jakiejś metodzie:

public function create() {
    return $this->_objectManager->create(/* ......... */);
}

Ta odpowiedź dotyczy wersji Magento 2.2 poniżej, więc proszę zanotować. Zgodnie z nowymi standardami Magento 2 nie możemy teraz używać nawet instancji objectManager. Musimy użyć fabryki klasy obiektu lub repozytorium, aby uzyskać jakiekolwiek dane.

Głównym powodem, dla którego programiści są mocno zniechęceni do bezpośredniego korzystania z Menedżera obiektów, jest to, że bezpośrednie użycie Menedżera obiektów powoduje, że rozszerzenia nie można zainstalować w trybie kompilacji.

W związku z tym dla klientów korzystających z trybu zwolnienia, w tym wszystkich klientów korzystających z Magento Cloud, przestaje działać.

Wygląda na to, że dość duży odsetek programistów (około 75%) nie testuje swoich rozszerzeń, aby sprawdzić, czy można je zainstalować w trybie wydania, więc nie napotykaj problemów związanych z nieprawidłowym użyciem ObjectManager.

Od 2017 r. Magento Marketplace przeprowadza test kompilacji i instalacji na wszystkich sprzedawanych za jego pomocą rozszerzeniach. Jeśli twoje rozszerzenie korzysta bezpośrednio z Object Managera, nie przejdzie tych testów i zostanie odrzucone z Marketplace, dopóki nie rozwiążesz tego problemu i przeładujesz.

Możesz spróbować, tworząc obiekt objectManager i nie powinieneś bezpośrednio używać objectManager .

Użyj czegoś takiego jak

class Example extends \Magento\Framework\View\Element\Template
{
    private $_objectManager;

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

    public function getExample()
    {
        $customerSession = $this->_objectManager->create("Magento\Customer\Model\Session");
        if ($customerSession->isLoggedIn()) {
            $customerData = $customerSession->getCustomer()->getData();
            /*Your logic*/
        }
    }
}