Prática recomendada do Magento 2 para locais e nomes de turmas

Em Magento 1que éramos usados ​​para colocar nossas classes nesses diretórios

• Quadra
• Ajudante
• Modelo
• Recurso

e use um nome de classe simples sem letras maiúsculas no meio do nome.

Se dermos uma olhada em alguns casos em Magento 2 Core

Ajudantes

Localização :
- \Foo\Bar\Helper
Nome :
- *.php
Exemplos :
- \Magento\ImportExport\Helper\Report
-\Magento\Cms\Helper\Wysiwyg\Images

Observadores

Localização :
- \Foo\Bar\Observer
Nome :
- *.php
- *Observer.php
Exemplos :
- \Magento\CustomerCustomAttributes\Observer\SalesOrderAddressAfterLoad
-\Magento\CustomerBalance\Observer\ProcessBeforeOrderPlaceObserver

Plugins

Localização :
- \Foo\Bar\Plugin
Nome :
- *.php
- *Plugin.php
Exemplos :
- \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

Localização :
- \Foo\Bar\Model
Nome :
- *ConfigProvider.php
Exemplos :
- \Magento\Tax\Model\TaxConfigProvider
-\Magento\Payment\Model\IframeConfigProvider

Minhas perguntas são:

• Se houver good/ bad/ bestpráticas para isso em Magento 2?
• Se eu quiser criar um costume, DataProviderpor exemplo, o que será?
  • \Foo\Bar\Provider\CustomDataProvider
  • \Foo\Bar\DataProvider\Custom
  • \Foo\Bar\Model\Provider\CustomDataProvider
  • \Foo\Bar\Helper\Provider\CustomDataProvider
• Como determinar a construção do nome e local da classe, uma pasta na raiz do módulo, no Model, no Helper, etc?
• Depende da fonte / tipo de dados recuperados?
• Quando precisamos adicionar o sufixo ao nome da classe?

O Magento 2 não está restrito como Magento 1 a apenas algumas pastas, como bloco, auxiliar, modelo e assim por diante.
Basicamente, você pode colocar uma classe em qualquer pasta que desejar. Cabe a você, já que a classe é instanciada usando o nome completo da classe, sem aliases, como no Magento 1.

Minha recomendação é agrupá-los pela funcionalidade.

• observadores em Vendor/Module/Observer.
• plugins em Vendor/Module/Plugin
• fornecedores de dados em Vendor/Module/DataProvider.
• classes relacionadas ao componente da interface do usuário em Vendor/Module/Ui

mas tente evitar a duplicação de nomes. Quero dizer, Vendor/Module/DataProvider/CustomDataProviderseria redundante.

Talvez o sufixo possa ser adicionado apenas para interfaces, embora as pessoas argumentem contra.

Para resumir, cabe a você como fazê-lo, apenas seja consistente.

Do ponto de vista da funcionalidade, não é importante onde você coloca as classes. Você pode até enlouquecer com eles e colocar todos eles diretamente na Vendor/Modulepasta, mas provavelmente não quer isso.

Eu acho (mas não tenho certeza) que a única restrição é que os controladores devem estar na pasta Controller.

Eu acho que é baseado em opinião, mas concordo que existem algumas inconsistências em relação à nomeação e localização de classes no M2.

Aqui está a lista que eu criei sobre a nomeação de pastas. Para mim, você sempre deve usar essas pastas quando puder, a fim de tornar seu módulo mais fácil de navegar e entender por qualquer outra pessoa:

• Quadra
• Controlador
• Modelo
• Observador
• Configuração
• Teste
• Ui
• etc
• i18n
• Visão
• Cron
• Ajudante
• Console
• Api
• Plugar
• DataProvider

Além disso, o M2 usa algumas pastas muito específicas, mas eu não as incluí nesta lista:

• Preços
• Aplicativo
• Dados do cliente
• Serviço
• Porta de entrada
• arquivos
• Adaptador
• Componente
• TemplateEngine

O bom do M2 é que você pode usar e criar qualquer pasta que precisar. Se algo não pertencer à lista acima, crie sua própria pasta e coloque suas classes nelas, apenas tente ser consistente.

Eu acho que a principal prioridade deve ser tornar o código o mais documentado possível. Portanto, em vez de colocar tudo nos diretórios Model ou Helper, encontrar um bom nome que descreva o que o código abaixo faz é uma abordagem melhor. Claro, também é mais difícil porque requer muito mais pensamento.

Por exemplo, em vez de usar Model/Config/Converter.php, o nome OrderStateMachine/TransitionsConfiguration/XmlToArrayConverter.phpdiz muito mais o que um módulo e uma classe fazem.

Já existem algumas respostas realmente boas acima. O que eu gostaria de acrescentar é que você deve evitar colocar o código abaixo app/codee usar um método de instalação baseado em compositor, que acabará colocando o código abaixo vendor/.