Revenir
en haut

Magento, alors, c’est comment ?

16/12/2010 9

Par la force des choses, j’ai été poussé à m’intéresser profondément à Magento, la solution e-commerce basée sur Zend Framework.

Le constat est très mitigé, après des heures et des heures sur le code, voilà ce que j’en tire.

Globalement

L’outil est très inaccessible. Pas de documentation efficace, une grosse communauté mais très peu réactive (aucune réponse sur les forums sur des questions critiques). Des heures et des heures de recherche, le plus souvent dans la source, pour réussir à s’en sortir en ayant toujours à l’esprit : « Est-ce que je ne suis pas en train de prendre des raccourcis ? »

Ceci n’enlève pas la qualité du produit mais joue beaucoup dans la décision finale. Développer avec Magento, c’est long. Ça sera difficile pour la plupart des développeurs, et ne parlons même pas des néophytes. Pour créer un module, accrochez vous. Vous passerez par des phases enchantées mais aussi par des phases de déprime totale :)

Par contre, si vous n’avez aucune spécificité technique particulière, vous aurez entre les mains un outil qui excelle dans la gestion d’une e-boutique. L’installation standard contient déjà la plupart des modules nécessaires à une boutique robuste : gestion de multiples « vues » (pour le multilingue par ex.), attributs des produits très flexibles, gestion des promotions, des newsletters, très bons outils de reporting, etc. etc.

D’un point de vue technique

Modèle de données EAV

L’organisation des données dans Magento repose sur le modèle EAV, acronyme pour Entity-Attribute-Value. Ce modèle de données permet de définir des entités dont le nombre d’attributs peut être très vaste et scalable. Ceci grâce à une séparation de l’entité et de ses paires attribut/valeur. En théorie, ce modèle de données est relativement simple.

En base de données, l’entité est stockée avec très peu d’attributs. La plupart du temps une clé primaire, des clés étrangères, et quelques attributs universels (par exemple la référence d’un produit).

Les attributs sont stockés dans une table commune à toutes les entités (liées par clé étrangère) qui contient tout type d’information : identifiant, nom, label, type (int, char, etc.), certaines contraintes (pour la validation par ex.).

Les valeurs sont souvent stockées dans des tables spécifiques avec comme clé étrangère l’identifiant de l’attribut. Mais pas toujours, dans des implémentations simples du modèle EAV les paires attribut/valeur peuvent être stockées dans la même table.

Sur le papier c’est très prometteur. Mais en pratique ça devient vite impraticable. Cette modélisation rend le code beaucoup plus difficile à déchiffrer. Les requêtes deviennent très complexes en plus d’être très coûteuses en ressources (beaucoup de jointures).

Bien que très flexible, cette modélisation est pour moi une manière de pervertir une base de données relationnelle. Et dans le cas de Magento, le modèle EAV force MySQL à se comporter d’une façon pour laquelle il n’est pas du tout prévu.

Mais qu’il en soit ainsi, les développeurs de Magento ont choisi la flexibilité par dessus la simplicité. Ce n’est pas nécessairement une mauvaise chose, mais vous êtes avertis :)

L’implémentation du modèle EAV dans Magento est très poussée, il faut chercher dans beaucoup de tables pour une seule entité mais le modèle objet rend heureusement les choses plus faciles. Mais attention, il faut éviter le plus possible d’avoir recours à des requêtes SQL pures, sinon je vous promet qu’il vous manquera quelques cheveux à la fin de l’exercice !

Architecture de Magento et qualité du code

Ce sujet est très sensible. En tant qu’architecte et développeur web averti, je reste dubitatif.

L’architecture du système regorge de bonnes idées, parfois ingénieuses, mais leurs implémentations laissent parfois un arrière goût d’anti bonnes pratiques. Mais globalement je dois avouer que je suis surpris par la réflexion qui a été menée sur ce projet. Je ne m’attendais pas à quelque chose d’aussi poussé.

La vue dans Magento

Magento propose une implémentation particulière de la couche présentation (vues) du modèle MVC.

Dans une implémentation classique, le contrôleur prépare le modèle et le donne à la vue qui n’a plus qu’à afficher les données correctement formatées.

Dans Magento, la vue elle-même est décortiquée en une architecture particulière. Tout repose sur un système de layout regroupant des « blocks » qui sont des portions de vue autonomes. Si on ferme les yeux sur les conséquences en termes de performances, cette modélisation est une véritable surprise.

Le contrôleur prépare toujours le modèle mais ne le passe pas à une vue. Il le stocke simplement dans un « registre » que chaque block pourra ensuite consulter pour récupérer les données nécessaires à l’affichage.

Une vue est un regroupement de blocks dont l’organisation est définie par un fichier XML, le layout.

Un block est un objet autonome totalement découplé du système qui peut être inclus dans n’importe quelle page du site et à n’importe quel moment. Il est composé concrètement d’une classe contenant des méthodes accessibles directement depuis un « template » (vocabulaire Magento pour le fichier phtml) qui met en forme le block (code HTML).

Si on essaie grossièrement de faire l’analogie avec une application Zend Framework classique, on peut dire que l’objet block est un regroupement d’aides de vue (view helpers), et que le template est la vue.

Je trouve ce système très bien foutu, et il montre une très grande flexibilité.

Mais attention (toujours un « mais »), cette architecture ouvre plus encore la porte vers les mauvaises pratiques. C’est à dire l’utilisation d’une couche pour laquelle elle n’est pas prévue.

Si vous vous demandez encore quel est précisément le rôle de chaque couche dans le paradigme MVC, ça sera pire avec Magento. Et c’est précisément le problème ici, beaucoup de développeurs utiliseront malheureusement le block comme un contrôleur d’actions, et un tel découplage laisse présager un véritable foutoir dans certains projets.

Création de module dans Magento

Je n’ai pas grand chose à dire sur cette partie. Une fois le système de block et la couche « Modèle » bien assimilés, la création de module ne devrait pas vous poser de problèmes. Si ce n’est quelques spécificités comme par exemple si vous souhaitez inclure une galerie d’images administrable (bon courage avec ça :p).

L’utilisation du modèle EAV n’est pas obligatoire, vous pouvez très bien définir des entités et les implémenter de manière classique.

La seule contrainte est l’utilisation abondante de XML pour configurer le module, et l’absence de documentation précise vous promet quelques heures de recherche.

L’ajout d’un module dans l’administration du site est un peu délicat au début (notamment les formulaires), mais une fois le baptême du feu passé, vous irez beaucoup plus vite. Magento propose des widgets permettant de créer « facilement » des grilles pour vos collections de données et des formulaires pré-formatés pour la modification de votre modèle.

Dans Magento tout doit être fait manuellement, en programmation. Si vous vous attendiez à créer simplement votre boutique à l’aide de la souris et d’une interface type CMS, c’est raté, vous devrez implémenter vous même vos modèles, contrôleurs, blocks et templates, comme vous le feriez avec Zend Framework (mais en plus complexe :p).

CMS

Ça va être très court. Le CMS de Magento laisse vraiment à désirer. Si vous comptiez inclure des pages de contenu avec une mise en page un peu recherchée et qui seraient administrables par le CMS, vous pouvez lâcher tout de suite l’affaire.

Ce module est plus qu’insuffisant et vous fera parfois abandonner Magento au profit d’un véritable CMS quitte à se contenter d’un module e-commerce très limité.

Le CMS vous permet de créer des pages ou des blocks statiques. Le petit plus est qu’il permet d’inclure des variables ou des blocks dynamiques au sein de votre page grâce à des « insert tags ».

Pour le reste, le CMS vous permet de modifier le layout XML de la page directement dans l’admin plutôt que dans un fichier. Il y a peu d’intérêt, sauf si vous formez votre client et qu’il se sent capable de modifier le layout, mais je dis attention ! :)

Les petits plus

Magento regorge de petites options pratiques, surtout pour les développeurs. Bien sûr c’est relatif, c’est pratique dans un contexte où tout est complexe :)

Vous pouvez activer par exemple un mode de traduction qui vous permet de traduire les clés CSV directement dans le site. Ou encore activer un débuggueur, configurer des notifications pour vos tâches CRON, réunir tous les fichiers javascript et CSS en un seul fichier, etc etc.

Je citerai aussi Magento Connect et son écosystème de modules qui est vraiment très appréciable. Il s’agit en fait d’un GUI (interface) qui vous permet de déclencher des installations et des mises à jour façon PEAR, tout ça avec la souris. Les versions des modules sont bien gérées, mais attention tout de même à ne pas installer n’importe quoi.

Conclusion

Vous l’aurez compris, l’apprentissage de Magento demande une certaine maîtrise du développement et beaucoup d’investissement.

Cet article est un premier retour sur l’architecture du projet et je ne prétend pas maîtriser l’outil au point que mes arguments soient considérés comme une vérité générale. Si vous n’êtes pas d’accord avec certaines idées, n’hésitez pas à vous exprimer.

Je ne peux aussi pas faire le tour de toutes les possibilités dans un seul article. Je n’ai par exemple pas parlé du SEO ou de la gestion des droits, et j’en passe.

Bien que j’admire certaines parties du système, j’émets de grosses réserves sur les performances avec un catalogue produits conséquent (> à 5000 produits).

Je trouve aussi dommage que Varien n’ait pas fait plus d’efforts sur la documentation et ne propose pas de mieux guider les développeurs dans le choix de cette solution. C’est un véritable frein et beaucoup de développeurs abandonneront en cours de route.

Néanmoins, Magento reste pour le moment et pour moi, la Rolls des solutions e-commerce libres sur le marché.

9 commentaires :

  1. Retour très intéressant :) !

  2. yves :

    pas mal le retour d’expérience. pour avoir passer 2 semaines sous magento. je peux dire le vrai gros problème pour moi reste le manque de documentation à la Zend framework.

  3. Damien :

    Très bonne analyse ! Je pratique Magento depuis un peu plus d’1 an et je partage globalement ton analyse avec quelques petites différences surtout concernant l’EAV qui certes est complexe et pas hyper performant mais dans les faits avec une utilisation correcte de l’API ça pose pas tant de problème que ça même sur des boutiques avec énorménent de produits (>100 000). En revanche pour ses propres modèles ça n’a pas vraiment d’intérêt.

    Pour résumé, oui des choses sont bien pensées (layout, block, observer, …), le CMS est très limité, la qualité du code est aléatoire et la documentation est inexistante voire périmée.

    • ça pose pas tant de problème que ça même sur des boutiques avec énorménent de produits (>100 000)

      Merci Damien pour cette précision :)

  4. Qu’en est-il des tests unitaires et fonctionnels? le code est couvert?

    • Non, malheureusement il y a une absence totale de tests unitaires.

      C’est la première chose que j’ai voulu regarder pour comprendre comment fonctionne le système, mais raté :)

      Je pense qu’au moment de la création de la plateforme les tests unitaires n’étaient pas encore une pratique très courante dans le monde PHP, c’est bien dommage.

  5. Pingback: Un retour sur la mise en place de Magento… | Magento

  6. Eddz :

    Très bonne analyse, merci.

  7. Super article très complet.

    Bravo :)

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.

*

Tags HTML autorisés : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
Tag code : [cc lang="langage"][/cc] (ex. [cc lang="php"][/cc])