Forse mi manca un punto, ma mi chiedo solo perché a volte esiste un'istruzione "use" per una classe specifica e altre volte no.

Esempio:, app\code\Magento\Email\Model\Template.phpabbiamo nella parte superiore del file:

namespace Magento\Email\Model;

use Magento\Store\Model\ScopeInterface;
use Magento\Store\Model\StoreManagerInterface;

Quindi nel __constructmetodo abbiamo i seguenti parametri:

public function __construct(
    \Magento\Framework\Model\Context $context,
    \Magento\Framework\View\DesignInterface $design,
    \Magento\Framework\Registry $registry,
    \Magento\Store\Model\App\Emulation $appEmulation,
    StoreManagerInterface $storeManager,
    \Magento\Framework\View\Asset\Repository $assetRepo,
    \Magento\Framework\Filesystem $filesystem,
    \Magento\Framework\App\Config\ScopeConfigInterface $scopeConfig,
    \Magento\Email\Model\Template\Config $emailConfig,
    \Magento\Email\Model\TemplateFactory $templateFactory,
    \Magento\Framework\Filter\FilterManager $filterManager,
    \Magento\Framework\UrlInterface $urlModel,
    \Magento\Email\Model\Template\FilterFactory $filterFactory,
    array $data = []
)

Quindi possiamo vedere chiaramente che come abbiamo chiamato use Magento\Store\Model\StoreManagerInterface;in cima alla classe, siamo in grado di fare StoreManagerInterface $storeManageri parametri del costruttore.

Le mie domande sono:

• Perché lo facciamo solo per una lezione?
• Perché non possiamo aggiungere useun'istruzione per ogni classe del costruttore in modo da non dover digitare il percorso completo della classe?
• O viceversa, perché non ci liberiamo usedell'istruzione e digitiamo il percorso completo della StoreManagerInterfacelezione?

Non vi è alcun motivo tecnico per preferire l'uno all'altro, tranne se ci sono conflitti di nomi (come diverse classi "Contesto"). Ma quelli possono essere risolti con alias ed è quello che faccio di solito:

use Magento\Framework\Model\Context as ModelContext;

Mi assumo che nelle centrali molti metodi, specialmente i costruttori, sono stati generati da strumenti come lo strumento di conversione in un primo momento e poi non cambiato usare importazioni "usa".

Quindi suggerirei che nel tuo codice importi sempre le classi con "use" per rendere il codice effettivo meno dettagliato e più leggibile.

L'utilizzo dipende dalla situazione specifica. Il mio approccio è:

Classe menzionata una sola volta all'interno di un file - FQN

Lascia un nome completo . Ciò migliora la leggibilità perché non è necessario rivedere la sezione d' uso .

Nome della classe usato più volte - importazione

Mettilo in una sezione d' uso . Questo rende il codice più breve in cui viene menzionata la classe.

Classe usata una volta ma ho bisogno di una breve notazione: importazione

Meglio spiegare con un esempio.

FQN

$collection->getSelect()
           ->joinInner(['campaign_products' => $subSelect],
               'campaign_products.product_id = e.entity_id',
               [self::FIELD_SORT_ORDER => "IFNULL(IF(0 = " . \Custome\Module\Api\Data\ProductListInterface::SORT_ORDER . ", NULL, " . \Custome\Module\Api\Data\ProductListInterface::SORT_ORDER . "), {$defaultSortValue})"]
           );

importare

$collection->getSelect()
           ->joinInner(['campaign_products' => $subSelect],
               'campaign_products.product_id = e.entity_id',
               [self::FIELD_SORT_ORDER => "IFNULL(IF(0 = " . ProductListInterface::SORT_ORDER . ", NULL, " . ProductListInterface::SORT_ORDER . "), {$defaultSortValue})"]
           );

Secondo me il secondo esempio è più facile da leggere. (Ma onestamente preferirei usare le variabili invece delle costanti qui per dare ancora più leggibilità.)

Interfacce API Magento 2

C'è un avviso riguardo agli endpoint API esposti automaticamente a M2. Nelle interfacce utilizzate per i metodi REST / SOAP dovresti sempre usare gli FQN.

Le annotazioni vengono analizzate da Magento Framework per determinare come convertire i dati da e verso JSON o XML.

Le importazioni di classe (ovvero le istruzioni use above the class) non vengono applicate!