Najlepsza praktyka Magento 2 dotycząca lokalizacji i nazw klas

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?

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.

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ść.

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.

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/.