Best practice per Magento 2 per posizioni e nomi delle classi

In Magento 1eravamo abituati a mettere le nostre classi in queste directory

• Bloccare
• aiutante
• Modello
• Risorsa

e usa un semplice nome di classe senza maiuscole nel mezzo del nome.

Se diamo un'occhiata ad alcuni casi in Magento 2 Core

Helpers

Posizione :
- \Foo\Bar\Helper
Nome :
- *.php
Esempi :
- \Magento\ImportExport\Helper\Report
-\Magento\Cms\Helper\Wysiwyg\Images

Gli osservatori

Posizione :
- \Foo\Bar\Observer
Nome :
- *.php
- *Observer.php
Esempi :
- \Magento\CustomerCustomAttributes\Observer\SalesOrderAddressAfterLoad
-\Magento\CustomerBalance\Observer\ProcessBeforeOrderPlaceObserver

plugin

Posizione :
- \Foo\Bar\Plugin
Nome :
- *.php
- *Plugin.php
Esempi :
- \Magento\Catalog\Plugin\Block\Topmenu
- \Magento\PageCache\Model\App\FrontController\BuiltinPlugin
Fonte : http://devdocs.magento.com/guides/v2.0/extension-dev-guide/plugins.html#declaring-a-plugin

ConfigProvider

Posizione :
- \Foo\Bar\Model
Nome :
- *ConfigProvider.php
Esempi :
- \Magento\Tax\Model\TaxConfigProvider
-\Magento\Payment\Model\IframeConfigProvider

Le mie domande sono:

• Se ci sono good/ bad/ bestpratiche per questo in Magento 2?
• Se voglio creare un'abitudine, DataProviderad esempio, quale sarà?
  • \Foo\Bar\Provider\CustomDataProvider
  • \Foo\Bar\DataProvider\Custom
  • \Foo\Bar\Model\Provider\CustomDataProvider
  • \Foo\Bar\Helper\Provider\CustomDataProvider
• Come determinare la costruzione del nome e della posizione della classe, una cartella nella radice del modulo, in Modello, in Helper, ecc.?
• Dipende dall'origine / tipo di dati recuperati?
• Quando dobbiamo aggiungere il suffisso al nome della classe?

Magento 2 non è limitato come Magento 1 a poche cartelle come blocco, supporto, modello e così via.
In pratica puoi posizionare una classe in qualsiasi cartella desideri. Dipende da te poiché la classe viene istanziata usando il nome completo della classe non con alias come in Magento 1.

La mia raccomandazione è di raggrupparli in base alla funzionalità.

• osservatori in Vendor/Module/Observer.
• plug-in Vendor/Module/Plugin
• fornitori di dati in Vendor/Module/DataProvider.
• ui classi relative ai componenti in Vendor/Module/Ui

ma cerca di evitare la duplicazione dei nomi. Voglio dire Vendor/Module/DataProvider/CustomDataProvidersarebbe ridondante.

Forse il suffisso può essere aggiunto solo per le interfacce, anche se le persone potrebbero discuterne.

Riassumendo, dipende da te come lo fai, basta essere coerenti in esso.

Dal punto di vista della funzionalità non è importante dove si posizionano le classi. Puoi persino impazzire con loro e metterli tutti direttamente nella Vendor/Modulecartella, ma probabilmente non lo vuoi.

Penso (ma non del tutto sicuro) che l'unica limitazione sia che i controller devono essere nella cartella Controller.

Credo che sia basato sull'opinione, ma sono d'accordo che ci sono alcune incongruenze riguardo alla denominazione delle classi e alle posizioni in M2.

Ecco l'elenco che ho creato per quanto riguarda la denominazione delle cartelle. Per me dovresti sempre usare quelle cartelle quando puoi per rendere il tuo modulo più facile da navigare e capire per chiunque altro:

• Bloccare
• controllore
• Modello
• Osservatore
• Impostare
• Test
• Ui
• eccetera
• i18n
• Visualizza
• cron
• aiutante
• consolle
• Api
• Collegare
• DataProvider

Inoltre, M2 utilizza alcune cartelle molto specifiche ma non le ho incluse in questo elenco:

• Prezzi
• App
• Dati dei clienti
• Servizio
• porta
• File
• Adattatore
• Componente
• TemplateEngine

La cosa buona di M2 è che puoi usare e creare qualunque cartella ti serva. Se qualcosa non appartiene all'elenco sopra, crea la tua cartella e inserisci le tue classi semplicemente cerca di essere coerente.

Penso che la massima priorità dovrebbe essere quella di rendere il codice il più autocompattante possibile. Quindi, piuttosto che mettere tutto nelle directory Model o Helper, trovare un buon nome che descriva cosa fa il codice sottostante è un approccio migliore. Certo, è anche più difficile perché richiede molto più pensiero.

Ad esempio, anziché utilizzare Model/Config/Converter.php, il nome OrderStateMachine/TransitionsConfiguration/XmlToArrayConverter.phpdice molto di più su ciò che fa un modulo e una classe.

Ci sono già alcune risposte davvero buone sopra. Quello che vorrei aggiungere è che dovresti evitare di mettere il codice sotto app/codee invece usare un metodo di installazione basato sul compositore che finirà per mettere il tuo codice sotto vendor/.