Mejores prácticas de Magento 2 para ubicaciones y nombres de clase

En Magento 1estábamos acostumbrados a colocar nuestras clases en estos directorios

• Bloquear
• Ayudante
• Modelo
• Recurso

y use un nombre de clase simple sin letras mayúsculas en el medio del nombre.

Si echamos un vistazo a algunos casos en Magento 2 Core

Ayudantes

Ubicación :
- \Foo\Bar\Helper
Nombre :
- *.php
Ejemplos :
- \Magento\ImportExport\Helper\Report
-\Magento\Cms\Helper\Wysiwyg\Images

Observadores

Ubicación :
- \Foo\Bar\Observer
Nombre :
- *.php
- *Observer.php
Ejemplos :
- \Magento\CustomerCustomAttributes\Observer\SalesOrderAddressAfterLoad
-\Magento\CustomerBalance\Observer\ProcessBeforeOrderPlaceObserver

Complementos

Ubicación :
- \Foo\Bar\Plugin
Nombre :
- *.php
- *Plugin.php
Ejemplos :
- \Magento\Catalog\Plugin\Block\Topmenu
- \Magento\PageCache\Model\App\FrontController\BuiltinPlugin
Fuente : http://devdocs.magento.com/guides/v2.0/extension-dev-guide/plugins.html#declaring-a-plugin

ConfigProvider

Ubicación :
- \Foo\Bar\Model
Nombre :
- *ConfigProvider.php
Ejemplos :
- \Magento\Tax\Model\TaxConfigProvider
-\Magento\Payment\Model\IframeConfigProvider

Mis preguntas son:

• Si hay alguna good/ bad/ bestprácticas para eso en Magento 2?
• Si quiero crear una personalizada, DataProviderpor ejemplo, ¿cuál será?
  • \Foo\Bar\Provider\CustomDataProvider
  • \Foo\Bar\DataProvider\Custom
  • \Foo\Bar\Model\Provider\CustomDataProvider
  • \Foo\Bar\Helper\Provider\CustomDataProvider
• ¿Cómo determinar la construcción del nombre y ubicación de la clase, una carpeta en la raíz del módulo, en Modelo, en Ayudante, etc.?
• ¿Depende de la fuente de datos recuperada / tipo de datos?
• ¿Cuándo tenemos que agregar el sufijo al nombre de la clase?

Magento 2 no está restringido como Magento 1 a solo unas pocas carpetas como block, helper, model, etc.
Básicamente, puede colocar una clase en la carpeta que desee. Depende de usted, ya que las clases se instancian usando el nombre completo de la clase, no con alias como en Magento 1.

Mi recomendación es agruparlos por la funcionalidad.

• observadores en Vendor/Module/Observer .
• complementos en Vendor/Module/Plugin
• proveedores de datos en Vendor/Module/DataProvider .
• clases relacionadas con el componente ui en Vendor/Module/Ui

pero trata de evitar la duplicación de nombres. quiero decirVendor/Module/DataProvider/CustomDataProvider sería redundante.

Quizás el sufijo se puede agregar solo para interfaces, aunque la gente argumentaría en contra de él.

Para resumir, depende de usted cómo lo haga, solo sea coherente.

Desde el punto de vista de la funcionalidad, no es importante dónde coloca las clases. Incluso puede volverse loco con ellos y colocarlos todos directamente enVendor/Module carpeta, pero probablemente no quiera eso.

Creo (pero no estoy completamente seguro) que la única restricción es que los controladores deben estar en la carpeta Controller.

Creo que está basado en opiniones, pero estoy de acuerdo en que hay algunas inconsistencias con respecto a la asignación de nombres de clase y ubicaciones en M2.

Aquí está la lista que se me ocurrió con respecto a la denominación de carpetas. Para mí, siempre debe usar esas carpetas cuando pueda para hacer que su módulo sea más fácil de navegar y comprender para cualquier otra persona:

• Bloquear
• Controlador
• Modelo
• Observador
• Preparar
• Prueba
• Ui
• etc.
• i18n
• ver
• Cron
• Ayudante
• Consola
• Api
• Enchufar
• Proveedor de datos

Además de eso, M2 utiliza algunas carpetas muy específicas, pero no las he incluido en esta lista:

• Precios
• Aplicación
• Información de los clientes
• Servicio
• Puerta
• Archivos
• Adaptador
• Componente
• TemplateEngine

Lo bueno de M2 ​​es que puedes usar y crear cualquier carpeta que necesites. Si algo no pertenece a la lista anterior, cree su propia carpeta y coloque sus clases en ellas solo trate de ser coherente.

Creo que la máxima prioridad debería ser hacer que el código sea tan autodocumentable como sea posible. Entonces, en lugar de poner todo en directorios Model o Helper, encontrar un buen nombre que describa lo que hace el código debajo es un mejor enfoque. Por supuesto, también es más difícil porque requiere mucha más reflexión.

Por ejemplo, en lugar de usar Model/Config/Converter.php, el nombre OrderStateMachine/TransitionsConfiguration/XmlToArrayConverter.phpdice mucho más de lo que hacen un Módulo y una clase.

Ya hay algunas respuestas realmente buenas arriba. Lo que me gustaría agregar es que debe evitar colocar el código debajo app/codey, en su lugar, usar un método de instalación basado en el compositor que terminará colocando su código debajo vendor/.