Najlepsza praktyka Magento 2 dotycząca lokalizacji i nazw klas

15

W Magento 1byliśmy przyzwyczajeni do umieszczania naszych klas w tych katalogach

  • Blok
  • Pomocnik
  • Model
  • Ratunek

i użyj prostej nazwy klasy bez wielkich liter w środku nazwy.

Jeśli spojrzymy na niektóre przypadki w Magento 2 Core

Pomocnicy

Lokalizacja :
- \Foo\Bar\Helper
Nazwa :
- *.php
Przykłady :
- \Magento\ImportExport\Helper\Report
-\Magento\Cms\Helper\Wysiwyg\Images


Obserwatorzy

Lokalizacja :
- \Foo\Bar\Observer
Nazwa :
- *.php
- *Observer.php
Przykłady :
- \Magento\CustomerCustomAttributes\Observer\SalesOrderAddressAfterLoad
-\Magento\CustomerBalance\Observer\ProcessBeforeOrderPlaceObserver


Wtyczki

Lokalizacja :
- \Foo\Bar\Plugin
Nazwa :
- *.php
- *Plugin.php
Przykłady :
- \Magento\Catalog\Plugin\Block\Topmenu
- \Magento\PageCache\Model\App\FrontController\BuiltinPlugin
Źródło : http://devdocs.magento.com/guides/v2.0/extension-dev-guide/plugins.html#declaring-a-plugin


ConfigProvider

Lokalizacja :
- \Foo\Bar\Model
Nazwa :
- *ConfigProvider.php
Przykłady :
- \Magento\Tax\Model\TaxConfigProvider
-\Magento\Payment\Model\IframeConfigProvider


Moje pytania to:

  • Jeśli są jakieś praktyki good/ bad/ bestw tym Magento 2?
  • Jeśli chcę utworzyć niestandardowy, DataProviderna przykład, co to będzie?
    • \Foo\Bar\Provider\CustomDataProvider
    • \Foo\Bar\DataProvider\Custom
    • \Foo\Bar\Model\Provider\CustomDataProvider
    • \Foo\Bar\Helper\Provider\CustomDataProvider
  • Jak określić konstrukcję nazwy i lokalizacji klasy, folderu w katalogu głównym modułu, w Modelu, w Pomocniku itp.?
  • Czy to zależy od pobranego źródła danych / typu danych?
  • Kiedy musimy dodać przyrostek do nazwy klasy?


Część odpowiedzi dla Virtual Types: https://community.magento.com/t5/Magento-DevBlog/Virtual-Types-Naming-Convention/ba-p/61510

Matthéo Geoffray
źródło

Odpowiedzi:

10

Magento 2 nie jest ograniczony jako Magento 1 tylko do kilku folderów, takich jak blok, pomocnik, model i tak dalej.
Zasadniczo możesz umieścić klasę w dowolnym folderze, który chcesz. To zależy od Ciebie, ponieważ tworzenie instancji klasy odbywa się przy użyciu pełnej nazwy klasy, a nie aliasów, jak w Magento 1.

Polecam pogrupować je według funkcjonalności.

  • obserwatorzy w Vendor/Module/Observer .
  • wtyczki Vendor/Module/Plugin
  • dostawcy danych w Vendor/Module/DataProvider .
  • klasy związane z komponentami interfejsu użytkownika w Vendor/Module/Ui

ale staraj się unikać powielania nazw. mam na myśliVendor/Module/DataProvider/CustomDataProvider byłoby zbędne.

Może sufiks można dodać tylko do interfejsów, chociaż ludzie się temu sprzeciwiają.

Podsumowując, od Ciebie zależy, jak to zrobisz, bądź konsekwentny.

Z punktu widzenia funkcjonalności nie jest ważne, gdzie umieszczasz klasy. Możesz nawet zwariować z nimi i umieścić je wszystkie bezpośrednio w Vendor/Modulefolderze, ale prawdopodobnie tego nie chcesz.

Myślę (ale nie do końca pewny), że jedynym ograniczeniem jest to, że kontrolery muszą znajdować się w folderze Controller.

Marius
źródło
Zgadzam się, że możemy zwariować, to zarówno dobry, jak i zły punkt, ale jak powiedziałeś, jest to zgodne z naszym sposobem postrzegania rzeczy. Może kiedy Magento podzieli się swoimi wewnętrznymi wizjami technicznymi ogłoszonymi na MagentoLive France, będziemy mieli więcej informacji na temat tych punktów. Dziękujemy za podzielenie się swoją opinią
Matthéo Geoffray
7

Uważam, że opiera się na opiniach, ale zgadzam się, że istnieją pewne niespójności dotyczące nazewnictwa klas i lokalizacji w M2.

Oto lista, którą wymyśliłem w sprawie nazewnictwa folderów. Dla mnie zawsze powinieneś używać tych folderów, gdy możesz, aby ułatwić przeglądanie i zrozumienie modułu dla innych:

  • Blok
  • Kontroler
  • Model
  • Obserwator
  • Ustawiać
  • Test
  • Ui
  • itp
  • i18n
  • widok
  • Cron
  • Pomocnik
  • Konsola
  • API
  • Podłącz
  • Dostawca danych

Ponadto M2 używa niektórych bardzo specyficznych folderów, ale nie umieściłem ich na tej liście:

  • cennik
  • App
  • Dane klienta
  • Usługa
  • Przejście
  • Akta
  • Adapter
  • Składnik
  • TemplateEngine

Zaletą M2 jest to, że możesz używać i tworzyć dowolne potrzebne foldery. Jeśli czegoś nie ma na powyższej liście, utwórz własny folder i umieść w nim swoje klasy, po prostu staraj się zachować spójność.

Raphael at Digital Pianism
źródło
We wszystkich twoich odpowiedziach odnajdujemy ten sam pomysł, możliwość robienia tego, co chcemy, najważniejsze jest zachowanie spójności i regularności w budowie. Jednak byłoby wspaniale, gdyby Magento podzieliło się wewnętrznymi wizjami na ten temat, gdy ogłosili to ML. Jak powiedziałeś, łatwiej będzie wszystkim zrozumieć rozszerzenia Core i Community. Dziękuję za odpowiedź.
Matthéo Geoffray
6

Myślę, że najwyższym priorytetem powinno być uczynienie kodu tak samo dokumentującym, jak to możliwe. Zamiast więc umieszczać wszystko w katalogach Model lub Helper, znalezienie dobrego imienia opisującego działanie kodu jest lepszym podejściem. Oczywiście jest to również trudniejsze, ponieważ wymaga dużo więcej myślenia.

Na przykład, zamiast używać Model/Config/Converter.php, nazwa OrderStateMachine/TransitionsConfiguration/XmlToArrayConverter.phpmówi znacznie więcej o tym, co robi moduł i klasa.

Vinai
źródło
Jak powiedziałeś, potrzeba więcej myślenia, aby było jasne dla nas, ale także dla każdego, kto widzi rozszerzenie. To sprawia, że ​​w tej chwili wszystko jest trudniejsze, ale z czasem bardziej skuteczne. Dziękuję za odpowiedź
Matthéo Geoffray
3

Powyżej jest już kilka naprawdę dobrych odpowiedzi. Chciałbym dodać, że powinieneś unikać umieszczania kodu pod, app/codea zamiast tego używać metody instalacyjnej opartej na kompozytorze, co spowoduje umieszczenie kodu pod vendor/.

Kristof w Fooman
źródło
Tak, nie martw się, jestem tego świadomy, format jest tylko dla przykładu w moim pytaniu :) Ale masz rację dla osób, które nie wiedzą, że dokonam edycji, aby było jasne. Dziękuję
Matthéo Geoffray
to jest dobry punkt fooman
Amit Bera