Quanti modelli di design ha Magento 2?
Quanti modelli di design ha Magento 2?
Risposte:
Modelli di design Magento 1/2
Parte 1: MVC
Magento utilizza un modello MVC unico, utilizzando un livello di configurazione basato su DOM. Sfrutta xml per guidare la configurazione e le azioni dell'applicazione in cima alla normale architettura Model-View-Controller.
Parte 2: Front Controller
Magento utilizza il modello Front Controller per implementare flussi di lavoro per la sua applicazione. Ha un unico punto di ingresso (index.php) per tutte le sue richieste. Vediamo come funziona tutto.
Parte 3: Fabbrica
Il metodo Factory viene utilizzato per istanziare le classi in Magento. Puoi creare un'istanza di una classe in Magento chiamando un metodo appropriato passando un nome astratto che rappresenta un gruppo di classi seguito da un nome di classe. I gruppi di classi e le relative astrazioni appropriate sono dichiarati nei file XML di configurazione nella cartella / etc / del modulo.
Parte 4: Singleton
Proprio come l'astrazione di classe di fabbrica e gruppi di classi in Magento, il modello Singleton è istanziato per blocchi e classi allo stesso modo.
Parte 5: Registro
Il modello di registro è fondamentalmente un modello che consente a qualsiasi oggetto o dato di essere disponibile in un ambito globale pubblico per l'utilizzo di qualsiasi risorsa.
Parte 6: prototipo
Il modello Prototype in Magento viene utilizzato come estensione del modello Abstract Factory. Assicura che venga creata un'istanza di una sottoclasse appropriata tramite i tipi appropriati assegnati a un oggetto. Cosa significa questo? Fondamentalmente, significa che ogni volta che è necessario ottenere una classe specifica definita tramite il suo tipo genitore, il modello prototipo ti assicura la classe giusta in grado di gestire ciò di cui hai bisogno.
Parte 7: Pool di oggetti
Il modello di pool di oggetti mantiene gli oggetti pronti per l'uso più e più volte invece di ri-istanziarli e distruggerli una volta terminato. È un ottimo modo per risparmiare sul consumo di memoria e sui cicli di calcolo.
Parte 8: Iteratore
Il modello Iterator è un modello di progettazione che consente a un oggetto di attraversare gli elementi di un'altra classe. Ciò consente di specificare un iteratore e consentire il passaggio di più insiemi di dati diversi senza modificare la struttura sottostante che consente l'iterazione.
Parte 9: Caricamento lento
Lazy Loading è un modello di progettazione che ritarda il caricamento di un oggetto fino al momento in cui l'oggetto viene richiamato. Con Magento, non lo utilizzano con oggetti, ma dati.
Parte 10: Service Locator
Il localizzatore di servizi è un modello di progettazione che consente all'utente di ottenere un servizio incapsulando il processo all'interno di un livello di astrazione. Ciò consente all'utente di recuperare il servizio appropriato o migliore senza sapere quale servizio è in fase di esecuzione.
Parte 11: Modulo
Il modello di progettazione del modulo è una forma di programmazione modulare che enfatizza il raggruppamento delle funzionalità di un programma in moduli indipendenti e intercambiabili.
Parte 12: osservatore
Il modello di osservatore è il punto in cui un listener di eventi è impostato a un certo punto durante l'esecuzione di un'applicazione. Altri componenti dell'applicazione possono "agganciarsi" a questo listener di eventi ed eseguire il loro codice durante questo punto.
Parte 13: Record attivo
Gli oggetti sono una rappresentazione di una riga nella tabella del database. Questi oggetti dovrebbero avere proprietà che riflettono le colonne che rappresentano la struttura della tabella e metodi per consentire la modifica di queste proprietà nel database.
L'uso del modello di Magento
Le classi che ereditano dopo la classe Mage_Core_Model_Abstract hanno accesso ai metodi load (), save () ed delete () che consentono il caricamento, la modifica, la creazione o l'eliminazione di record in una tabella a cui è connessa la classe. Inoltre, la classe Mage_Core_Model_Abstract eredita da Varien_Object, il che ci dà accesso a metodi veramente magici __set () e __get () che sono responsabili della mappatura automatica delle colonne in una tabella del database con le proprietà di un determinato oggetto.
Aggiunta Magento 2
MODELLO DI PROGETTAZIONE DEL CONTRATTO DI ASSISTENZA
Magento è un sistema basato su estensioni o modulare, che consente a uno sviluppatore di terze parti di personalizzare e sovrascrivere parti fondamentali del proprio framework. Queste personalizzazioni possono portare a diversi problemi, ad esempio, diventerà per gli sviluppatori tenere traccia della personalizzazione effettuata da estensioni esterne. In tal modo, per superare questo Magento viene fuori un modello di contratto di servizio. Un contratto di assistenza è un insieme di interfacce che agiscono come un livello tra un utente finale e un livello aziendale. Pertanto, anziché esporre direttamente la logica aziendale per la personalizzazione all'utente finale, si inserisce un livello chiamato contratto di servizio.
I contratti di assistenza migliorano la modularità di Magento. Aiuta i commercianti a semplificare l'aggiornamento di Magento Garantire API ben definite e durature implementate da altri moduli esterni e Magento. Fornire un modo semplice per esporre la logica di business tramite interfacce REST o SOAP.
RESPONSABILE DELL'OGGETTO
È composto da vari modelli come: - Iniezione delle dipendenze, Singleton, Fabbrica, Fabbrica astratta, Composito, strategia, CQRS, Decoratore e molti altri. Discuteremo alcuni dei modelli più utilizzati tra questi. Il gestore degli oggetti ha un ruolo molto importante da svolgere, Magento ne proibisce l'uso diretto. Il gestore oggetti è responsabile dell'implementazione dei modelli factory, singleton e proxy. Istanzia automaticamente il parametro nei costruttori di classi. Prima di spostare il futuro, facciamo capire gli oggetti iniettabili e non iniettabili: -
OGGETTI INIETTABILI
Non hanno una propria identità come EventManager, CustomerAccountManagementService.
OGGETTI NON INIETTABILI
Come cliente, prodotto, ecc. Queste entità di solito hanno le loro identità e il loro stato, poiché hanno le loro identità è importante sapere su quale istanza esatta dell'entità dobbiamo lavorare.
INIEZIONE DI DIPENDENZA
È un'alternativa al Mago in magento 1. È un concetto di iniezione dell'oggetto dipendente attraverso un ambiente esterno piuttosto che crearlo internamente. Quindi chiederemo risorse quando verrà creato il nostro oggetto invece di creare risorse quando necessario. Questo aiuta nelle future modifiche e test diventa molto semplice deridendo gli oggetti richiesti.
MODELLO DI FABBRICA O CLASSI DI FABBRICA:
In Magento 2 le classi Factory creano un livello tra il gestore oggetti e il codice aziendale. Le classi di fabbrica non devono essere definite in modo esplicito poiché sono generate automaticamente. Dovremmo creare classi di fabbrica per oggetti non iniettabili.
MOTIVO PROSSIMO
Le classi proxy vengono utilizzate al posto di un'altra classe e in Magento 2 vengono talvolta utilizzate al posto di classi affamate di risorse. Per capire quali sono le classi proxy, vediamo il motivo che porta al verificarsi delle classi proxy. Come sappiamo Magento usa l'iniezione del costruttore per la creazione di oggetti e quando creiamo un'istanza di un oggetto tutte le classi nel suo costruttore creeranno un'istanza, portando così a una catena di istanziazioni tramite un costruttore, questo può davvero rallentare il processo e influire sulle prestazioni di un'applicazione , quindi per interrompere l'istanza a catena Magento utilizza le classi proxy.
Vediamo il seguente codice: -
Magento\Catalog\Model\Product\Attribute\Source\Status\Proxy
Magento\Catalog\Model\Product\Link\ProxyQuindi nel codice sopra, stiamo usando le classi proxy per catalogProductStatus e productLink. Quando corriamo
php bin/magento setup:di:compile Magento crea al volo classi proxy usando di.xml con alcune convenzioni fisse, sostituendo così l'oggetto originale con un oggetto classe proxy. Ora diamo un'occhiata alla nostra classe proxy per capire come funziona
Seguono alcune convenzioni comuni di Magento durante la creazione del proxy: -
Plugin (intercettori)
Panoramica
Un plug-in, o intercettore, è una classe che modifica il comportamento delle funzioni della classe pubblica intercettando una chiamata di funzione ed eseguendo il codice prima, dopo o attorno a quella chiamata di funzione. Ciò consente di sostituire o estendere il comportamento di metodi pubblici originali per qualsiasi classe o interfaccia.
Le estensioni che desiderano intercettare e modificare il comportamento di un metodo pubblico possono creare una classe Plugin che viene definita plug-in.
Questo approccio di intercettazione riduce i conflitti tra estensioni che modificano il comportamento della stessa classe o metodo. L'implementazione della classe Plugin modifica il comportamento di una funzione di classe, ma non cambia la classe stessa. Poiché possono essere chiamati in sequenza in base a un ordinamento configurato, questi intercettori non sono in conflitto tra loro.
limitazioni
I plug-in non possono essere utilizzati con nessuno dei seguenti:
ObjectManager
Panoramica
Le applicazioni di grandi dimensioni, come ad esempio l'applicazione Magento, utilizzano un gestore oggetti per evitare il codice della caldaia durante la composizione di oggetti durante l'istanza.
Nel framework Magento, l'implementazione di ObjectManagerInterface svolge le funzioni di un gestore oggetti.
responsabilità
Il gestore oggetti ha le seguenti responsabilità:
Creazione di oggetti in fabbriche e proxy. Implementare il modello singleton restituendo la stessa istanza condivisa di una classe quando richiesto. Gestione delle dipendenze creando un'istanza della classe preferita quando un costruttore richiede la sua interfaccia. Istanza automatica dei parametri nei costruttori di classi. https://devdocs.magento.com/guides/v2.0/extension-dev-guide/object-manager.html