Magento 2 Best Practice für Kursorte und -namen

In Magento 1diesen Verzeichnissen haben wir unsere Klassen abgelegt

• Block
• Helfer
• Modell
• Ressource

Verwenden Sie einen einfachen Klassennamen ohne Großbuchstaben in der Mitte des Namens.

Schauen wir uns einige Fälle in Magento 2 Core

Helfer

Ort :
- \Foo\Bar\Helper
Name :
- *.php
Beispiele :
- \Magento\ImportExport\Helper\Report
-\Magento\Cms\Helper\Wysiwyg\Images

Beobachter

Ort :
- \Foo\Bar\Observer
Name :
- *.php
- *Observer.php
Beispiele :
- \Magento\CustomerCustomAttributes\Observer\SalesOrderAddressAfterLoad
-\Magento\CustomerBalance\Observer\ProcessBeforeOrderPlaceObserver

Plugins

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

ConfigProvider

Ort :
- \Foo\Bar\Model
Name :
- *ConfigProvider.php
Beispiele :
- \Magento\Tax\Model\TaxConfigProvider
-\Magento\Payment\Model\IframeConfigProvider

Meine Fragen sind:

• Gibt es irgendwelche good/ bad/ bestPraktiken dafür in Magento 2?
• Wenn ich DataProviderzum Beispiel eine benutzerdefinierte erstellen möchte, welche wird es sein?
  • \Foo\Bar\Provider\CustomDataProvider
  • \Foo\Bar\DataProvider\Custom
  • \Foo\Bar\Model\Provider\CustomDataProvider
  • \Foo\Bar\Helper\Provider\CustomDataProvider
• Wie kann man den Aufbau des Klassennamens und des Speicherorts, eines Ordners im Stammverzeichnis des Moduls, in Model, in Helper usw. bestimmen?
• Kommt es auf die abgerufene Datenquelle / den Datentyp an?
• Wann müssen wir das Suffix zum Klassennamen hinzufügen?

Magento 2 ist als Magento 1 nicht auf wenige Ordner wie Block, Helfer, Modell usw. beschränkt.
Grundsätzlich können Sie eine Klasse in einem beliebigen Ordner ablegen. Es liegt an Ihnen, da die Klasse unter Verwendung des vollständigen Klassennamens instanziiert wird, nicht mit Aliasen wie in Magento 1.

Meine Empfehlung ist, sie nach der Funktionalität zu gruppieren.

• Beobachter in Vendor/Module/Observer.
• Plugins in Vendor/Module/Plugin
• Datenanbieter in Vendor/Module/DataProvider.
• Komponentenbezogene Klassen in Vendor/Module/Ui

Vermeiden Sie jedoch doppelte Namen. Ich meine, Vendor/Module/DataProvider/CustomDataProviderwäre überflüssig.

Vielleicht kann das Suffix nur für Schnittstellen hinzugefügt werden, obwohl die Leute dagegen argumentieren würden.

Zusammenfassend ist es an Ihnen, wie Sie es tun, nur in ihm konsequent zu sein.

Aus funktionaler Sicht ist es nicht wichtig, wo Sie die Klassen platzieren. Sie können sogar verrückt nach ihnen werden und sie alle direkt in einem Vendor/ModuleOrdner ablegen, aber das möchten Sie wahrscheinlich nicht.

Ich denke (aber nicht ganz sicher), dass die einzige Einschränkung darin besteht, dass sich die Controller im Ordner befinden müssen Controller.

Ich denke, es ist meinungsbasiert, aber ich stimme zu, dass es einige Inkonsistenzen in Bezug auf Klassennamen und Orte in M2 gibt.

Hier ist die Liste, die ich zur Benennung von Ordnern erstellt habe. Für mich sollten Sie diese Ordner immer verwenden, wenn Sie können, um das Durchsuchen und Verstehen Ihres Moduls für andere zu erleichtern:

• Block
• Regler
• Modell
• Beobachter
• Installieren
• Prüfung
• Ui
• etc
• i18n
• Aussicht
• Cron
• Helfer
• Konsole
• Api
• Plugin
• Datenanbieter

Darüber hinaus verwendet M2 einige sehr spezifische Ordner, die ich jedoch nicht in diese Liste aufgenommen habe:

• Preisgestaltung
• App
• Kundendaten
• Bedienung
• Tor
• Dateien
• Adapter
• Komponente
• TemplateEngine

Das Gute an M2 ist, dass Sie jeden Ordner verwenden und erstellen können, den Sie benötigen. Wenn etwas nicht in die obige Liste gehört, erstellen Sie einen eigenen Ordner und ordnen Sie Ihre Klassen darin ein. Versuchen Sie einfach, konsistent zu sein.

Ich denke, die oberste Priorität sollte darin bestehen, den Code so selbstdokumentierend wie möglich zu gestalten. Anstatt alles in Model- oder Helper-Verzeichnissen abzulegen, ist es besser, einen guten Namen zu finden, der beschreibt, was der Code darunter bewirkt. Natürlich ist es auch schwieriger, weil es viel mehr Nachdenken erfordert.

Beispielsweise sagt Model/Config/Converter.phpder Name OrderStateMachine/TransitionsConfiguration/XmlToArrayConverter.phpviel mehr aus , als dass er verwendet wird , was ein Modul und eine Klasse tun.

Es gibt oben bereits einige wirklich gute Antworten. Was ich hinzufügen möchte, ist, dass Sie vermeiden sollten, Code unter zu platzieren, app/codeund stattdessen eine composer-basierte Installationsmethode verwenden, die Ihren Code unter zu platzieren endet vendor/.