Combien de modèles de conception possède Magento 2?
15
Magento 1/2 Design Patterns
Partie 1: MVC
Magento utilise un modèle MVC unique, utilisant une couche de configuration basée sur DOM. Il utilise xml pour piloter la configuration et les actions de l'application en plus de l'architecture Model-View-Controller standard.
Partie 2: contrôleur avant
Magento utilise le modèle Front Controller pour implémenter des workflows pour son application. Il a un point d'entrée unique (index.php) pour toutes ses demandes. Voyons comment tout cela fonctionne.
Partie 3: Usine
La méthode Factory est utilisée pour instancier des classes dans Magento. Vous instanciez une classe dans Magento en appelant une méthode appropriée en passant un nom abstrait représentant un groupe de classes suivi d'un nom de classe. Les groupes de classes et leurs abstractions appropriées sont déclarés dans vos fichiers XML de configuration dans le dossier / etc / de votre module.
Partie 4: Singleton
Tout comme l'abstraction de classe d'usine et les groupes de classe dans Magento, le modèle Singleton est instancié pour les blocs et les classes de la même manière.
Partie 5: Registre
Le modèle de registre est fondamentalement un modèle qui permet à tout objet ou donnée d'être disponible dans une portée globale publique pour n'importe quelle ressource à utiliser.
Partie 6: Prototype
Le modèle Prototype dans Magento est utilisé comme une extension du modèle Abstract Factory. Il garantit qu'une sous-classe appropriée est instanciée via des types appropriés qui sont affectés à un objet. Qu'est-ce que ça veut dire? Fondamentalement, cela signifie que chaque fois que vous devez obtenir une classe spécifique définie via son type parent, le modèle de prototype garantit que vous obtenez la bonne classe qui peut gérer ce dont vous avez besoin.
Partie 7: Pool d'objets
Le modèle de pool d'objets garde les objets prêts à l'emploi encore et encore au lieu de les réinstancier et de les détruire une fois terminés. C'est un excellent moyen d'économiser sur la consommation de mémoire et les cycles de calcul.
Partie 8: Itérateur
Le modèle d'itérateur est un modèle de conception qui permet à un objet de traverser les éléments d'une autre classe. Cela vous permet de spécifier un itérateur et de laisser passer plusieurs ensembles de données différents sans modifier la structure sous-jacente qui permet l'itération.
Partie 9: Chargement paresseux
Le chargement différé est un modèle de conception qui retarde le chargement d'un objet jusqu'au moment où l'objet est appelé. Avec Magento, ils ne l'utilisent pas avec des objets, mais des données.
Partie 10: Localisateur de services
Le localisateur de services est un modèle de conception qui permet à un utilisateur d'obtenir un service en encapsulant le processus à l'intérieur d'une couche d'abstraction. Cela permet à l'utilisateur de récupérer le service approprié ou le meilleur sans savoir ce qu'est ce service au moment de l'exécution.
Partie 11: Module
Le module Design Pattern est une forme de programmation modulaire qui met l'accent sur le regroupement des fonctionnalités d'un programme en modules indépendants et interchangeables.
Partie 12: Observateur
Le modèle d'observateur est l'endroit où un écouteur d'événements est défini à un certain point pendant l'exécution d'une application. D'autres composants de l'application peuvent «s'accrocher» à cet écouteur d'événements et exécuter leur code pendant ce point.
Partie 13: enregistrement actif
Les objets sont une représentation d'une ligne dans la table de base de données. Ces objets doivent avoir des propriétés qui reflètent les colonnes représentant la structure de la table et des méthodes permettant de modifier ces propriétés dans la base de données.
L'utilisation du motif par Magento
Les classes qui héritent après la classe Mage_Core_Model_Abstract ont accès aux méthodes load (), save () et delete () qui permettent de charger, modifier, créer ou supprimer des enregistrements dans une table à laquelle la classe est connectée. De plus, la classe Mage_Core_Model_Abstract hérite de Varien_Object, qui nous donne accès à des méthodes vraiment magiques __set () et __get () qui sont responsables du mappage automatique des colonnes d'une table de base de données avec les propriétés d'un objet donné.
Addition Magento 2
MODÈLE DE CONCEPTION DE CONTRAT DE SERVICE
Magento est un système basé sur une extension ou modulaire, qui permet à un développeur tiers de personnaliser et d'écraser les parties principales de son framework. Ces personnalisations peuvent entraîner plusieurs problèmes, par exemple, il deviendra pour les développeurs de garder une trace de la personnalisation effectuée par les extensions externes. Ainsi, pour surmonter ce problème, Magento propose un modèle de contrat de service. Un contrat de service est un ensemble d'interfaces qui agissent comme une couche entre un utilisateur final et une couche métier. Ainsi, plutôt que d'exposer directement la logique métier pour la personnalisation à l'utilisateur final, une couche appelée contrat de service se situe entre les deux.
Les contrats de service améliorent la modularité de Magento. Aide les commerçants pour une mise à niveau facile de Magento Assurez une API bien définie et durable que les autres modules externes et Magento implémentent. Fournissez un moyen simple d'exposer la logique métier via des interfaces REST ou SOAP.
GESTIONNAIRE D'OBJETS
Il se compose de différents modèles tels que: - Injection de dépendances, Singleton, Factory, Abstract Factory, Composite, stratégie, CQRS, Decorator et bien d'autres. Nous allons discuter de certains modèles les plus utilisés parmi ceux-ci. Le gestionnaire d'objets a un très grand rôle à jouer, Magento en interdit l'utilisation directe. Le gestionnaire d'objets est responsable de l'implémentation des modèles d'usine, singleton et proxy. Il instancie automatiquement le paramètre dans les constructeurs de classe. Avant de déménager le futur permet de comprendre les objets injectables et non injectables: -
OBJETS INJECTABLES
Ils n'ont pas leur propre identité comme EventManager, CustomerAccountManagementService.
OBJETS NON INJECTABLES
Tels que le client, le produit, etc. Ces entités ont généralement leur identité et leur état, car elles ont leur identité, il est important de savoir sur quelle instance exacte d'entité nous devons travailler.
INJECTION DE DÉPENDANCE
C'est une alternative à Mage dans magento 1. C'est un concept d'injecter l'objet dépendant à travers un environnement externe plutôt que de les créer en interne. Ainsi, nous demanderons des ressources lorsque notre objet est créé au lieu de créer des ressources en cas de besoin. Cela facilite les futures modifications et les tests deviennent très faciles en se moquant des objets requis.
MODÈLE D'USINE OU CLASSES D'USINE:
Dans Magento 2 Factory, les classes créent une couche entre le gestionnaire d'objets et le code métier. Les classes d'usine n'ont pas besoin de définir explicitement car elles sont générées automatiquement. Nous devons créer des classes d'usine pour les objets non injectables.
MODÈLE DE PROCURATION
Les classes proxy sont utilisées pour remplacer une autre classe et dans Magento 2, elles sont parfois utilisées à la place des classes gourmandes en ressources. Pour comprendre ce que font les classes proxy, voyons la raison qui conduit à l'apparition de classes proxy. Comme nous le savons, Magento utilise l'injection de constructeur pour la création d'objets et lorsque nous instancions un objet, toutes les classes de son constructeur instancient également, ce qui conduit à une chaîne d'instanciation via un constructeur, cela peut vraiment ralentir le processus et avoir un impact sur les performances d'une application. , donc pour arrêter l'instanciation de la chaîne, Magento utilise des classes proxy.
Voyons le code suivant: -
Magento\Catalog\Model\Product\Attribute\Source\Status\Proxy
Magento\Catalog\Model\Product\Link\ProxyDonc, dans le code ci-dessus, nous utilisons des classes proxy pour catalogProductStatus et productLink. Quand nous courons
php bin/magento setup:di:compile Magento crée des classes proxy à la volée en utilisant di.xml avec certaines conventions fixes, remplaçant ainsi l'objet d'origine par un objet de classe proxy. Voyons maintenant notre classe proxy pour comprendre comment elle fonctionne
Certaines conventions courantes que Magento suit lors de la création d'un proxy: -
Plugins (Intercepteurs)
Aperçu
Un plugin, ou intercepteur, est une classe qui modifie le comportement des fonctions de classe publique en interceptant un appel de fonction et en exécutant du code avant, après ou autour de cet appel de fonction. Cela vous permet de remplacer ou d'étendre le comportement des méthodes publiques originales pour n'importe quelle classe ou interface.
Les extensions qui souhaitent intercepter et modifier le comportement d'une méthode publique peuvent créer une classe Plugin qui sont appelés plugins.
Cette approche d'interception réduit les conflits entre les extensions qui modifient le comportement de la même classe ou méthode. L'implémentation de votre classe Plugin modifie le comportement d'une fonction de classe, mais elle ne change pas la classe elle-même. Parce qu'ils peuvent être appelés séquentiellement selon un ordre de tri configuré, ces intercepteurs n'entrent pas en conflit les uns avec les autres.
Limites
Les plugins ne peuvent pas être utilisés avec l'un des éléments suivants:
ObjectManager
Aperçu
Les grandes applications, telles que l'application Magento, utilisent un gestionnaire d'objets pour éviter le code passe-partout lors de la composition d'objets lors de l'instanciation.
Dans le framework Magento, l'implémentation de ObjectManagerInterface remplit les fonctions d'un gestionnaire d'objets.
Responsabilités
Le gestionnaire d'objets a les responsabilités suivantes:
Création d'objets dans les usines et les mandataires. Implémentation du modèle singleton en renvoyant la même instance partagée d'une classe lorsque cela est demandé. Gestion des dépendances en instanciant la classe préférée lorsqu'un constructeur demande son interface. Instanciation automatique des paramètres dans les constructeurs de classe. https://devdocs.magento.com/guides/v2.0/extension-dev-guide/object-manager.html