Magento 2 – Was ändert sich bei der Entwicklung von Modulen?

Magento 2 ist seit kurzem verfügbar, und jeder hat nun Gelegenheit, sich mit den Besonderheiten der neuen Software zu beschäftigen. Mit der Unterstützung von PHP 5.5 bzw. bald PHP 7, dem Datenbanksystem mySQL 5.6, der neuesten Webserver-Versionen von Nginx und Apache sowie dem Einsatz von Varnish und Redis Cache bereits in der CE ist Magento 2.0 sicher eines der modernsten Shopsoftwaresysteme.

%CAD2%

Magento 2 zeichnet sich aber nicht nur durch die unterstützten Technologien aus, sondern auch – und vor allem – durch moderne Entwicklungsprinzipien. Was hat sich für Entwickler geändert und welchen Nutzen versprechen die innovative Softwarearchitektur und die neuen Entwicklungsmuster?

Module in Magento 2 – Erweiterbarkeit und Wartbarkeit

Eines vorweg: Magento 2 ist sicherlich komplexer als sein Vorgänger. Hat man sich aber erstmal an die veränderte Benamung der Magento Module und die neue Verzeichnisstruktur gewöhnt, eröffnet Magento 2 eine Vielzahl von Vorteilen, die die Entwicklungsarbeit aber auch die Pflege des Systems wesentlich vereinfachen.

Service Contracts

Von einer etwas höheren Abstraktionsebene aus betrachtet, ist Magento 2 noch stärker einem mehrschichtigen Softwaremodell  verpflichtet als Magento 1.X und wurde um einen Service Layer erweitert. Etwas konkreter geht es um den Einsatz von Service Contracts. Das sind PHP-Interfaces nach einem bestimmten Muster oder Design Pattern. Sie regeln die Art und Weise der Kommunikation zwischen Modulen. Der Austausch soll ausschließlich über diese vordefinierten Schnittstellen (Data und Service Interfaces) erfolgen, somit die Datenintegrität schützen sowie die Business Logic der Module voneinander getrennt halten. Die Service Contracts stellen dazu anderen Modulen und Extensions genau jene Funktionalitäten bzw. Methoden zur Verfügung, die sie für den definierten Fall auch benötigen. Durch die Einführung der Service Contracts steigt die Stabilität in der Kommunikation und der Zusammenarbeit von Modulen untereinander. Außerdem verbessert sich dadurch die Updatefähigkeit und Flexibilität des Gesamtsystems. Vorausgesetzt natürlich, man hält sich an das Prinzip.

Quelle: Magento

Konfiguration von Modulen

Im Bereich der Modul-Entwicklung gibt es etwa mit der Erweiterung der XML-Struktur eine deutliche Verbesserung. Anpassungen erfolgen nicht mehr nur über die globalen Konfigurationsdateien, sondern es lassen sich für jedes Modul eigene XML-Dateien erstellen. Damit steigt zwar deren Anzahl, andererseits ist es so möglich, ganz gezielt für jeden Einsatzzweck XML-Strukturen zu erstellen und über eigene XML Schema Definitionen (XSD) auf Korrektheit zu validieren. Die modulspezifischen XML-Dateien sind ein weiterer Baustein in der Modularisierung von Magento und sorgen für eine leichtere Pflege des Shopsystems.

Portierung zu Magento 2

Magento 1.x Module lassen sich nicht eins zu eins auf Magento 2 migrieren. Dankbarerweise liefert Magento mit einem automatischen Modul-Migrator aber ein brauchbares Tool, das den Entwicklern einen Teil ihrer Arbeit abnimmt. Aber eben nur einen Teil. Nachbesserungen sind dennoch nötig. Wer allerdings bei der Magento 1 Entwicklung auf eine hohe Codequalität und einen sauberen Aufbau seiner Module geachtet hat, wird nur mit einem minimalen Mehraufwand rechnen müssen. Manche Befürchtungen der ersten Stunde, die Portierung von Modulen werde zum finanziellen Risiko, haben sich ganz sicher nicht bewahrheitet. Hat man bereits in den bestehenden Magento-Modulen Dependency-Injection als Muster verwendet, wird die Migration nochmals einfacher.

Das Prinzip der Dependency Injection

Auch bei Dependency Injection handelt es sich um ein Design Pattern. Prinzipiell geht es darum, die Abhängigkeiten (dependencies) zwischen Modulen oder Klassen von Modulen nicht als einen Bestandteil der Module selbst zu definieren, sondern an eine zentrale Stelle zu delegieren. Damit werden die Abhängigkeiten zwischen den einzelnen Modulen quasi flexibel steuerbar, bzw. die Module werden unabhängiger. Dieser Mechanismus wurde nun auch in Magento 2 umgesetzt, und die Steuerung erfolgt über eine modulspezifische XML-Datei (di.xml). Die durchgängige Einführung von Dependency Injections in Magento 2 war ein weiterer wichtiger und notwendiger Schritt für die Optimierung der Magento Codebasis. Neben der Codequalität verbessern sich zudem die Testbarkeit und die Erweiterbarkeit einer Magento-Plattform. Letzteres, da sich Abhängigkeiten einfach austauschen lassen. Die Umsetzung des Mechanismus ist recht gut gelungen, wenn er auch noch kleinere Schwächen aufweist. Noch werden die Definitionen der Plugins und der Abhängigkeiten in der di.xml vermischt.

Plugins in Magento 2

Mit Plugins, oder noch genauer Interceptoren, erhält man in Magento 2 die Möglichkeit, gezielt einzelne öffentliche Methoden einer Klasse zu überschreiben, ohne dass es zu den von Magento 1 bekannten Rewrite-Konflikten kommt. In Magento 1 konnte bisher immer nur ein Modul eine Methode überschreiben. Über Plugins können nun mehrere Module die gleiche Methode erweitern und sich dabei vor, nach oder um die betroffene Methode schalten. Allerdings werden die Plugin-Definitionen ebenfalls in der di.xml vorgenommen. Bei umfangreichen Modulen kann dies dazu führen, dass eine di.xml sehr viele Definitionen umfasst und die Trennung zwischen den Dependency-Injections und den Plugin-Definitionen schwer fällt.

Diese Kleinigkeiten ändern aber nichts mehr am äußerst positiven Gesamteindruck der Software. Vollzieht man den Paradigmenwechsel erfolgreich nach, fällt die Programmierung in Magento 2 wirklich leicht und macht dann doch mehr Spaß als in Magento 1.

Autor: Matthias Walter , Senior Entwickler, netz98 new media GmbH