Les grandes évolutions techniques apportées par Magento 2
Cet article est constitué à partir de bonnes feuilles issues de la 2e édition de l'ouvrage sur Magento 2 de l’équipe de conseil et d’ingénierie, dédiée à Magento : X2i ».
Magento 2 est une application essentiellement écrite en PHP. Son code est entièrement orienté objet, ce qui assure son côté industriel, fiable et robuste. Elle dispose d'une architecture complexe et évoluée qui permet toute intégration de besoins métier spécifiques dans les sites e-commerce.
Les différences entre Magento 1 et Magento 2 sont importantes, nécessitant de nouvelles approches de conception et de développement.
1- Abandon du framework monolithique
Les briques à bas niveau de Magento 1, notamment sa Varien Library, reposent entièrement sur Zend Framework 1. Cette approche monolithique oblige parfois les développeurs à modifier profondément le comportement du noyau pour intégrer leurs fonctionnalités.
Avec Magento 2, les composants bas niveau peuvent venir de partout ! Le noyau utilise encore massivement des composants de Zend Framework 1, mais il met aussi en oeuvre quelques briques de Zend Framework 2 et de Symphony 2.
En résumé, Magento 2 prend le meilleur de ce qui existe, quel que soit son origine.
Le choix de conserver Zend Framework 1 est le simple résultat de l'analyse des gains, face au coût d'adaptation des modules, sachant que les cas bloquants pouvaient être réglés par l'utilisation de nouveaux composants.
Les développeurs habitués à Magento 1 constateront l'apparition d'un Magento Framework (dossier lib/internal/Magento/Framework) qui remplace la Varien Library de Magento 1. Les modules fonctionnels sont clairement séparés (dossier app/code/Magento). La notion de code pool (core, community et local) disparaît.
2- Architecture orientée service
L'architecture de Magento 1 est totalement orientée objet. Elle a été saluée par les développeurs e-commerce lors de sa sortie pour ses fondamentaux solides et sa capacité d'extension, grâce à ses composants (Varien Library et modules) et à une utilisation avancée de la programmation événementielle (events et observers).
Magento 2 y ajoute une approche majeure : l'architecture orientée service (SOA en anglais) dont les forces sont d'avoir une forte cohérence interne (gestion unifiée des objets et des données, utilisation du format pivot XML) et un couplage relativement ouvert avec les briques externes.
Cette nouvelle approche rend certaines habitudes Magento 1 totalement obsolètes… et c'est une très bonne nouvelle ! Les développeurs Magento avaient parfois des difficultés à surcharger des composants du noyau ou se noyaient dans une succession d'événements difficiles à tracer pendant les phases de test. Avec une approche par services, la modification du fonctionnement de Magento est à la fois simple, sûre et performante. Elle garantit surtout une parfaite intégration dans des systèmes d'information composés de multiples applications et services, répartis dans le monde entier, grande tendance de ces dernières années.
3- Service Contracts, le point d'entrée pour la logique métier des modules
Magento 1 avait déjà une approche modulaire lors de sa sortie en 2008. Son architecture évolutive et robuste avait d'ailleurs emballé les techniciens, avant que les commerçants ne s'intéressent à la richesse fonctionnelle. Cependant, il restait des dépendances fortes entre modules, ce qui interdisait certaines personnalisations poussées (désactivation de modules du noyau inutiles, enrichissement de modules, séparation logique / affichage…) et rendaient complexes les mises à jour (compatibilité des modules additionnels, adaptation des thèmes…).
Magento 2 apporte une réponse intéressante à ces points faibles par son système Service Contracts. Le principe est de séparer totalement les parties métier (blocs affichés, contrôle des actions, génération du code HTML, appels web services) des parties logiques et de manipulation des données (modèles, ressources, dépôts, services).
Chaque module propose son "contrat de services" (fournisseur de services), exploitable par les autres modules (clients des services) en toute indépendance de versions et de comportements. Un module peut donc évoluer, sans impacter ses "clients", tant que le "contrat reste le même.
Du coup, un module ne comporte qu'un seul point d'entrée à ses fonctionnalités, facilitant la courbe d'apprentissage des développeurs et la fiabilité des développements. Chaque fonctionnalité livrée en standard peut être étendue, supprimée ou remplacée sans aucun effet de bord, le Service Contracts agissant comme un aiguillage entre la demande métier, la logique technique et la restitution.
La couche Service Contracts est accessible par web services, via une API qui sait exploiter de fait toutes les fonctionnalités des modules. Un grand changement par rapport à Magento 1 !
Techniquement, les Service Contracts sont des interfaces PHP permettant un accès aux couches basses de Magento :
- Service Interfaces : manipulation des services
- Data Interfaces : structure et intégrité des données
Ces interfaces PHP sont définies dans le dossier api de chaque module. Un développeur peut donc voir rapidement les fonctionnalités proposées et implémenter les siennes, en utilisant des données encapsulées complètes (compte, client, commande, produit, etc.).
L'approche Service Contracts est un très bon reste de Fabric, un composant du projet X.Commerce imaginé par eBay, mais abandonné en 2012. L'isolation des modules est maintenant une réalité, les "effets de bord" n'existent plus, la plate-forme gagne en fiabilité.
4- Application des PSR
Soutenues par le PHP Framework Interop Group, les PHP Standard Recommendations (PSR) assurant que les bonnes pratiques de PHP sont appliquées lors du développement d'une application web.
Magento 2 utilise les PSR suivantes :
- Basic Coding Standard (PSR-1), définit les principes de base du codage PHP.
- Coding Style Guide (PSR-2), précise les styles d'écriture des éléments applicatifs (fonctions, classes, méthodes, propriétés, documentation, etc.).
- Autoloader (PSR-4), détermine comment les composants applicatifs doivent être automatiquement chargés.
L'application des PSR assure une mise en oeuvre très simple des outils de contrôle qualité utilisés communément. Faire la même chose avec Magento 1 est un exercice de persévérance assez coûteux…
5- Renforcement de la sécurité
Magento 1 est déjà une application réputée pour sa robustesse face aux attaques. Ses composants fonctionnels ont été conçus pour contrôler les informations entrantes, tracer les erreurs, isoler les risques.
Cependant, quelques mauvaises manipulations lors de la construction du site ou de son déploiement pouvaient ouvrir des portes intéressantes aux personnes mal intentionnées…
Magento renforce donc la sécurité à plusieurs niveaux, notamment sur les dossiers applicatifs. La racine du site n'est plus la racine des dossiers de Magento, mais le dossier pub. De fait, tous les autres dossiers sont inaccessibles publiquement depuis un navigateur web.
6- Refonte complète de la gestion des thèmes
Le fonctionnement des interfaces du frontend et du backend a fait l'objet d'une refonte complète. Les technologies les plus récentes ont été intégrées, comme HTML5, CSS3 et jQuery.
Mais les changements les plus importants se situent au niveau de l'architecture technique qui améliore la gestion des blocs de contenu et de la structure des pages. Elle offre aussi des outils d'automatisation et de génération pour produire et retoucher beaucoup plus rapidement les thèmes.
Le principal reproche concernant le web design sous Magento 1 est la coexistence au sein des thèmes des composants fonctionnels, des blocs de structuration des pages et des éléments de mise en forme. Cette imbrication oblige à retoucher les thèmes quand un module est modifié ou à vérifier le fonctionnement des modules quand c'est le thème qui évolue.
Avec Magento 2, le problème est résolu, grâce au concept de View qui sépare :
- les éléments fonctionnels, liés aux modules ;
- les éléments de structuration et de mise en forme du contenu des pages, liés aux thèmes.
Chaque module possède la définition de ses éléments d'interface et peut donc changer de comportement (évolution, mise à jour), sans devoir adapter le ou les thèmes qui l'exploitent. Inversement, la structure HTML des blocs d'un thème peut totalement changer sans perturber le fonctionnement des modules.
Autre changement important, les thèmes acceptent maintenant un nombre illimité de surcharges de thèmes (nommé fallbacks). Magento 1 n'acceptait que 3 niveaux : thème actif, puis thème par défaut de l'interface active, puis thème par défaut de l'interface de base. Cette nouveauté donne des possibilités de création incroyables et peu coûteuses !
Concernant la programmation des feuilles de styles, Magento propose des outils de conception basés sur une approche LESS, un pré-processeur permettant d'étendre le langage CSS et simplifier la gestion des styles (voir www.lesscss.or). Bien entendu, ce n'est pas un passage obligé et les web designers peuvent travailler "à l'ancienne" (modification directe des fichiers .css) ou avec encore plus de possibilités (approche SASS par exemple).
7- Automatisation des tests
Magento 2 est livré avec des outils de tests extrêmement complets. Plusieurs types de tests permettent aux développeurs d'assurer la qualité de leur réalisation :
- Tests unitaires
- Tests fonctionnels
- Tests de l'API
- Tests des composants JavaScript
- Tests d'intégration
- Tests de performances
La couverture est complète, ce qui signifie que les conséquences de l'intégration d'un module tiers ou spécifique sur le comportement de la plate-forme peuvent être intégralement vérifiées. Une avancée majeure par rapport à Magento 1 !
Cet article est constitué à partir de bonnes feuilles issues de la 2e édition de l'ouvrage sur Magento 2 de l'équipe de conseil et d'ingénierie, dédiée à Magento : X2i ".
Lire aussi :
- Universal Analytics : comment suivre les transactions sur Magento ?