Webentwicklung mit Zend Framework: Export-Schnittstellen in Gambio

zend_framework_logo
Im folgenden möchte ich gerne exemplarisch an einem kleinen Software-Projekt aufzeigen, wie die Planung von Programmierungen aussehen kann. Hier lässt sich ganz gut nachvollziehen, nach welchen Kriterien die Entscheidung für oder gegen bestimmte Software gefällt wird.

Zu den Anforderungen: Die Applikation soll aus einer Shopsoftware automatisiert CSV-Dateien mit Bestelldaten an einen Logistiker versenden. Jede Bestellung soll nur einmalig exportiert werden.

Technisch ist das Vorgehen klar: ein Cron auf dem Server wird ein Skript aufrufen, das entsprechende nach Paramtern (Bestellstatus, Bestellung bereits exportiert) Bestellungen ausliest, verarbeitet, in eine CSV-Datei schreibt und diese per Mail versendet. Das bestehende Shopsystem (in dem Fall eine ältere Gambio-Installation) weist keine Plugin-Struktur auf. Aus der jahrelangen Praxis kann ich sagen: die Änderungen im eigentlichen Quellcode sollten so gering wie möglich ausfallen. Aller Fremdcode sollte möglichst zentral verwaltet werden und gekapselt vorliegen. In dem Fall ist das dankbarerweise einfach: der Cron ruft nur eine URL auf. Die Applikation muss nicht mit der Shop-Software interagieren, sondern kann getrennt von ihr arbeiten. In dem Fall ist das möglich und ratsam. Bei anderer Shop-Software wie Shopware oder Magento wäre erstmal zu prüfen, ob eine getrennte Anbindung überhaupt sinnvoll ist, oder nicht gleich ein Plugin entwickelt wird. Vorteil eines Plugins ist, dass ich Zugriff auf bestehende Methoden des Systems habe und z.B. direkt auf Order Models zugreifen kann.

Im konkreten Fall stellt sich die Frage, ob hier ein PHP-Framework zum Einsatz kommen soll. Eine meiner Anforderungen lautet: Dieses soll so klein wie möglich sein. Denn an sich benötige ich keine Controller und nahezu kein Routing, da ich nur Business-Logik implementieren muss. Dazu sollte das Framework auf einem günstigen Hosting laufen. Heisst: möglichst wenig Anforderungen an den Server aufweisen. Wenn ich per Console mit SSH zugreifen muss, könnte das u.U. schon eine Einschränkung bedeuten. Ebenso wie besondere PHP-Einstellungen, die ich bei Standard-Webhostings nicht beeinflußen kann. Eine PHP-Version > 5.2 kann ich dagegen voraussetzen.

Die Applikation wird keine Webseiten anzeigen, daher fallen Views weg. Eine Template-Engine benötige ich nicht und generell keine Proto-HTML-Files. Es wird kein HTML geben, just plain PHP. Emails werden versandt, hier geht es aber in erster Linie um die Anhänge (CSV Dateien), der Email-Content selbst wird kein HTML-beeinhalten, das bereitgestellt werden muss.

Ich benötige de facto auch keine vorgefertigten Models. Ansonsten finde ich es gut, wenn etwa CakePhp klare Vorgaben an die Datenbank-Benennungen macht (Convention over Configuration). In meinem Fall ist das kontraproduktiv, da ich an eine bestehende Applikation, in dem Fall ein xt:commerce 3.04-Derivat, ansetze.

Die Tabellen der originalen Datenbank kann ich schließlich nicht so umformatieren, dass sie mit der Framework-Logik d´accord gehen. Und ich möchte auch nicht endlos die Models konfigurieren und dort die Abhängigkeiten zwischen „orders“ und „orders_details“ modulieren. Ich benötige einfach einen sauberen Zugriff auf die Datenbank mit PDO, in dem potentielle Sicherheitslöcher direkt im Framework abgefangen werden.
Mein derzeitiger Favorit an Frameworks, Laravel, fällt damit weg. Eloquent ORM ist ähnlich wie Doctrine überdimensioniert für diesen Einsatzzweck. Frameworks sind das falsche Tool, wenn ich in einer Drittsoftware eingreifen will.

An der Stelle schält sich heraus: eigentlich ist ein MVC Framework überdimensioniert, wenn eine ganz einfache Applikation enstehen soll. Und hier komme ich an den Punkt, dass ich eigentlich eher eine Komponenten-Sammlung benötige. Speicherplatz wäre noch ein Argument: Alleine die Library von ZF1.12.3 kommt auf knapp 39MB. In Zeiten, in denen man selbst bei 10 Euro Hostings 250GB Festplattenspeicher bekommt eigentlich zu vernachlässigen, aber trotzdem ein Hinweis auf möglichen Overhead: Brauche ich das alles? An sich kann ich bei ZF auch einzelne Komponenten verwenden – allerdings muss ich dann prüfen, dass keine Abhängigkeiten zu anderen Komponenten vorliegen.

Fazit: Ich habe mich letztenendes für Zend Framework 1 entschieden. Ein für mich wichtiger Grund war die wegfallende Einarbeitungszeit. Mit ZF1 bin ich vertraut und kann recht schnell Ergebnisse erzielen. Dazu weiß ich, dass ich in der Implementierung nicht auf unangenehme Überraschungen stoßen werde. Knackpunkt ist wie erwähnt eine mögliche Kollision mit dem Shopsystem. Eine gewisse Grundstruktur der Applikation wäre auch nicht schlecht, also Bootstrap Design Pattern. Der Code sollte zentral in einem Verzeichnis liegen und dort aufrufbar sein mit einem URL-Aufruf über die index.php. All das geht mit ZF und ich kann mir hier aussuchen, ob ich etwa Zend_Application verwende oder meine eigene Basisklasse schreibe.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.