Verbesserungsvorschlag: Symfony Integration

[saithis]

Die Integration mit Symfony hätte diverse Vorteile, da dazu aber BC Breaks nötig sind, wäre mein Vorschlag für modified Shop Version 2 oder 3 (je nachdem wann ihr Version 2 releasen wollt...).

Vorteile:

• Viele Schnittstellen und MODs können in Bundles ausgelagert werden, wodurch der Shop Core leichter wartbar wird
• Symfony Components und Bundles können genutzt werden (Dependency Injection, Event Dispatcher, Translation, PayumPaymentBundle, usw.)
• Der Shop wird leichter integrierbar mit anderen Systemen
• Es entsteht potentiell besserer Code (Symfony zwingt einen mehr zu sauberem Code, aber manche Leute finden immer Wege den Code ins Chaos zu stürzen)
• Automatische Tests sind leichter umsetzbar
• Viele Leute kennen sich schon mit Symfony aus
• ...

Nachteile:

• Es ist eine große Umstellung
• Wer bisher noch nichts von Namespaces, Dependency Injection und co gehört hat, wird sich erstmal schwer tun (Lohnt sich aber es zu lernen! )
• Symfony nutzt zur Konfiguration yml Dateien, eventuell schwer das in die Datenbank auszulagern (hab es noch nie probiert...)

Mehr Nachteile fallen mir gerade nicht ein, bei den Vorteilen könnte ich noch ewig weiter aufzählen, aber die wichtigsten sind glaub ich gesagt.

Wenn man es richtig anstellt, kann man die Integration auch schrittweise vornehmen und kann somit schon teils von den Vorteilen profitieren, ohne sofort alles umschreiben zu müssen.

Ich hab mal auf Github ein Beispiel, wie das aussehen könnte, zusammengeschustert.
https://github.com/saithis/modified-shop/tree/symfony-integration

In meinem Code wird in der application_top.php der Symfony Kernel initialisiert, womit die Services (EventDispatcher, Doctrine, usw.) und die Bundles (Plugins) geladen werden.
Falls die includes/modules/default.php geladen wird, wird geschaut ob die übliche Shop Funktionalität aufgerufen werden soll, oder ob ein Symfony artiger URL Pfad übergeben wurde. Wenn es ein Symfony Pfad ist, wird die Symfony Funktion zum beantworten von Requests aufgerufen. Andernfalls wird der alte Shop Code ausgeführt. (Hier wären bei dem Symfony/Shop Switch noch Verbesserungen nötig, das ist nur eben kurz hingeschustert.)
In der application_bottom.php wird der Symfony Kernel terminiert.

Sollte der Vorschlag angenommen werden, wären das die weiteren nötigen Schritte:

• Session Konflikt lösen (Für den Anfang hat Symfony dazu einen Legacy mode)
• .htaccess von Symfony und Shop kombinieren
• Shop auf UTF-8 umstellen (oder Symfony auf ISO-8859-15 umstellen, was aber weniger sinnvoll wäre...)
• Dependency Injection Container im Shop zugänglich machen (z.B. um den EventDispatcher oder die DB Verbindung zu holen)
• xtc_db_* Funktionen umschreiben, damit sie per Default die Symfony Verbindung nutzen (Großteil der Arbeit schon erledigt, siehe hier)
• Events im Shop an wichtigen Stellen auslösen
• Templates-Ordner aus den Bundles zugänglich machen

Damit hätte man dann schon ein einfaches Plugin System und bis auf die UTF-8 Umstellung keine allzu großen BC Breaks.

Anschließend könnte man Schritt für Schritt die Schnittstellen in Bundles auslagern und den Shop langsam auf die Symfony Art umschreiben.

Linkback: https://www.modified-shop.org/forum/index.php?topic=30573.0

[Matt]

Bei Nachteile fehlt:
Performancebremse

Und für mich, der SQL schreiben und lesen kann, ist Doctrine deutlich zu unflexibel. Also muss man doch wieder drum rum arbeiten.

[saithis]

Das Booten des Symfony Kernels verlangsamt den Shop bei mir um 0,003 Sekunden ('prod' Environment und Debug false)... das ist ziemlich vernachlässigbar.
Zudem ist mein Laptop nicht grad der schnellste, hab nur einen Intel Core i5 M 560.

Bei Doctrine würde ich nur auf DBAL setzen, nicht ORM.
Somit kann man seine Queries wie bisher ganz normal per Hand schreiben, hat aber den Vorteil von Prepared Statements.
Das Umschreiben auf Doctrine hab ich hier auch schon gemacht und es ist rückwärts-kompatibel mit den aktuellen xtc_db_* aufrufen. Es müssen also nichtmal irgendwelche Queries umgeschrieben werden.

Somit sehe ich da keinen Nachteil.

[Matt]

Das Booten des Symfony Kernels verlangsamt den Shop bei mir um 0,003 Sekunden ('prod' Environment und Debug false)... das ist ziemlich vernachlässigbar.
Zudem ist mein Laptop nicht grad der schnellste, hab nur einen Intel Core i5 M 560.

Lies mal 60.000 Bestellungen aus der Datenbank mit entsprechenden Relationen zu Kunden, bestellten Produkten etc. aus. Dann weißt du was ich meine.

[saithis]

Dann lies bitte nochmal meinen vorigen Post, indem ich von der Verwendung von Doctrine DBAL geschrieben hab.
NICHT Doctrine ORM!

Doctrine DBAL ist nur ein kleiner Wrapper über die nativen DB connectors, um ein paar Zusatzfunktionen wie named parameters, nested transactions und co bereitzustellen.
Die SQL Queries schreibt man weiterhin per Hand, diese werden auch so wie man sie eingegeben hat an die DB geschickt und man bekommt ganz normal ein PHP array mit den Ergebnissen zurück.

Bei einem anderen Projekt (kein Shop) haben wir aktuell 2,8 Millionen Einträge in der größten Tabelle und diese hat diverse Relationen mit anderen Tabellen. Selbst da haben wir bei unseren Queries kein Problem mit Doctrine.

Edit:
Meintest du mit 60k Bestellungen auslesen, das du 60k mal eine API des Shops triggerst, indem er dir jedes mal eine Bestellung ausgibt?
In dem Fall würde es dann ca 3 Minuten länger dauern. Ist nicht die Welt, aber wenn dich diese 3 Minuten stören, könntest du immer noch ein extra Skript schreiben, das den Shop komplett umgeht. Dann würdest du vermutlich sogar weit mehr als diese 3 Minuten einsparen.

Meines Erachtens nach also trotzdem kein Dealbreaker.

[ShopNix]

... den Shop langsam auf die Symfony Art umschreiben.

Da wäre es sicher klüger, einen neuen Shop zu schreiben.

Tatsächlich kann man zwar eine Großmutter in ein Dirndl stopfen, aber sie sieht halt dann auch aus wie weiland das Merkel im Abendkleid.

Der Shop hat, so wie er ist, seine Berechtigung, und ich mag die Gründe gar nicht alle aufzählen. Aber er ist inzwischen sehr in die Jahre gekommen, da beißt die Maus keinen Faden ab.

Nehmen wir nur mal die Relationen, von denen Matt sprach. Modified nutzt kein RDMBS, es nutzt lediglich einen Dateneimer. Das Kapitel referentielle Integrität im Datenmodell wäre der erste Punkt, der umzusetzen wäre.

Bei der Gelegenheit müsste das gesamte Datenmodell des Shops auf den Prüfstand. Auf Anhieb fallen mir da die Gruppen im Crossselling ein, Mehrsprachigkeit auch in der Datenbank (schon alleine, weil es mich ankotzt, dass ich in Germany wohnen muss, statt in Deutschland), Artikelattribute als echte Artikel, so dass auch Bestände geführt werden können, ....

Dann die ganze Geschichte mit den Zahlungsmodulen. Aktuell ist es so, dass eine ganze Reihe von Zahlungsverfahren auf eigene Abschnitte im Core angewiesen sind. Das ist historisch gewachsen, der gute Harald hatte vermutlich auch keine zuverlässige Kristallkugel. Das macht's aber nicht besser.

Order-totals ist auch so ein Thema für sich.

Wir sollten der Tatsache in's Auge schauen: modified ist am Ende des Produktlebenszyklus angelangt. Das soll nicht heißen, dass die Software von heute auf morgen nicht mehr zu gebrauchen ist, aber es ist sinnlos, derartigen Aufwand in ein überaltertes Konzept zu stecken.

[saithis]

Einen neuen Shop zu schreiben würde halt deutlich länger dauern und dabei passiert es leicht, das auf der Strecke die Motivation aus geht und das Ganze im Sand verläuft.

Bei einer Schritt für Schritt Umstellung hätte man zwischendrin zumindest immer mal einen laufenden Stand.

Ansonsten geb ich dir aber recht.

[ShopNix]

Sehe ich ein, nur sollte man am Fundament anfangen, nicht mit dem Dachstuhl. Und als Fundament sehe ich das Datenmodell.

[saithis]

Ich finde das aktuell das größte Problem der zugemüllte Code ist. Überall ist der Code für die Zahlungsmodule, Schnittstellen, etc. verstreut. Solange der nicht weg ist, ist es viel schwerer überhaupt etwas am Code zu ändern.

Deshalb dieser Vorschlag hier, wodurch man den Zahlungsmodule/Schnittstellen/etc. Code in Bundles verbannen kann.
Anschließend kann man auch leichter tiefergreifende Änderungen vornehmen.

Zudem macht es mehr Sinn erst auf Doctrine zu wechseln und dann das Datenmodell zu ändern als andersrum, weil man dann gleich Prepared Statements nutzen kann, anstatt jeden Query noch ein 2. mal dafür anzufassen.

[ShopNix]

Ich finde das aktuell das größte Problem der zugemüllte Code ist. Überall ist der Code für die Zahlungsmodule, Schnittstellen, etc. verstreut. Solange der nicht weg ist, ist es viel schwerer überhaupt etwas am Code zu ändern.

Ein Kompromiss wäre vielleicht, zunächst gründlich zu entrümpeln. Der künftige Shop muß nicht von Anfang an alle Zahlungsmodule haben, er braucht keine Attribute, kein Cross-Selling, ...

Das kann wachsen, wenn die Basis stimmt.

Zudem macht es mehr Sinn erst auf Doctrine zu wechseln und dann das Datenmodell zu ändern als andersrum, weil man dann gleich Prepared Statements nutzen kann, anstatt jeden Query noch ein 2. mal dafür anzufassen.

Keineswegs. Mit welchen Mitteln ich auf ein Datenmodell zugreife, ist dem Datenmodell völlig wurscht.

Wo ich es ändere, muss ich auch die Queries ändern. Wo ich etwas neu machen muß, weil sich das Modell ändert, kann ich es mit neuen Mitteln tun.

Weil aber das Datenmodell das Fundament ist, muss das Datenmodell zuerst kommen.

[saithis]

Und wenn man die Queries ändert, ist es blödsinn es mit den alten xtc_db_* Funktionen zu tun. Dementsprechend sollte zuerst eine Alternative bestehen, um diese dann gleich zu nutzen und somit den Aufwand zu minimieren.

Meiner Meinung nach sollte die Reihenfolge Framework -> Datenmodell -> Implementierung sein.
Also erst das Vorbereiten der Symfony Integrierung + Entschlacken, dann das Datenmodell neu machen, dann das (Re-)implementieren von Funktionalität/Features.

[Hendrik1]

Nur eine Frage an die Profis.

wo ist dann der Unterschied zur Magento?

[noRiddle (revilonetz)]

Sehr interessante Statements hier.
  vor allem ShopNix,
aber auch saithis für das Anschneiden des Themas.

@saithis
Warum pochst du so sehr auf ein Framework wie Symfony ?
Konsequent objektorientiert zu programmieren ist sicherlich eine Herausforderung, insbesondere auch was Geschwindigkeit und somit Performance betrifft, ob ein Framework da unbedingt der richtige Kandidat ist um das umzusetzen ist fraglich, insbesondere da ein Framework immer auch Balast mit sich rumschleppt der nicht benötigt wird (siehe Bootstrap was CSS und Javascript betrifft).
Da wäre, wenn schon Framework, etwas wie Phalcon eher interessant da es auf C aufbaut und weit performanter ist als reine PHP-Frameworks.
(Ich muß natürlich zugeben, daß der Vergleich PHP-Framework - Bootstrap ein wenig hinkt.)

Das Problem bei den ganzen Ideen ist

• die mangelnde Bereitschaft backwards compatibility aufzugeben,
  was sicherlich ein gewichtiges Argument ist
• die Server-Konfigurationen die insbesondere bei Phalcon aber auch bei anderen Frameworks auf "shared hostings" nicht machbar sein werden,
  was wiederum die Verbreitung der Software stark einschränken würde

Würde man lediglich Punkt 1. brechen hätte man bessere Karten.
Wie ShopNix schon sagte,
Datenmodell verbessern/neu machen und wie ich sage, konsequent auf PDO gehen und, daraus erfließend, leichter Master-Slave-Implementationen für Attribute realisieren zu können.
Einen ersten Schritt, wenn er auch am bestehenden Core eher bastelt als ihn neu aufzustellen, versucht man mit der kommenden 2.0 zu gehen indem man MySQLi verwendet um weiterhin auch prozedural, in wichtigen Teilen aber eben auch objektorientiert arbeiten zu können.
Daß Zahlungs- und Versandmodule sowie das order_total-Modul ein "pain in the ar..." sind, ist bekannt aber eben nur konsequent zu ändern wenn man Punkt 1. über Bord wirft und grundsätzlich neu denkt.
Ob dabei ein Framework unbedingt das Gelbe vom Ei ist ist fraglich.

Gruß,
noRiddle

[saithis]

Warum objektorientiert:
Autoloading der Klassen, flexiblerer Code, aufgeräumteres Projekt (kein inc Ordner in dem einfach alles durcheinander drinen ist), bessere Wiederverwendbarkeit von Code.

Warum überhaupt ein Framework:
Weil man sich damit viel Arbeit spart. Wenn man z.B. ein Routing selber schreibt, dann hat man erstmal die Arbeit es zu schreiben und dann ist es noch lange nicht so gut durchgetestet wie das Symfony Routing, was von zig tausenden von Seiten benutzt wird.

Warum pochst du so sehr auf ein Framework wie Symfony ?

• Viele Features
• Viele andere Projekte nutzen es und sind somit leicht miteinander kombinierbar
• Rießen Community (und somit viele Leute die sich damit auskennen)
• Guter Support
• Dank Unit Tests wenige Bugs und falls man doch mal einen findet, wird er sehr schnell behoben
• Sehr flexibler Code
• Viele Bundles, wodurch man sich oft das selber Programmieren einer Funktionalität spart
• Gut skalierbar
• Gute Performance (viel läuft über Lazy Loading)
• Gutes Plugin System gleich mit dabei
• Animiert einen sauber und sicher zu programmieren (modified animiert einen aktuell eher zum zusammenhacken und stellt einem in Sachen Sicherheit eher das Bein)

Im Endeffekt ist es das Framework, mit dem ich bisher am am zufriedensten bin und am wenigsten Probleme hatte.

Das Problem bei den ganzen Ideen ist

• die mangelnde Bereitschaft backwards compatibility aufzugeben,
  was sicherlich ein gewichtiges Argument ist
• die Server-Konfigurationen die insbesondere bei Phalcon aber auch bei anderen Frameworks auf "shared hostings" nicht machbar sein werden,
  was wiederum die Verbreitung der Software stark einschränken würde

Solange der Shared Hosting Provider nicht irgend welche wichtigen PHP Funktionen deaktiviert hat, sollte Symfony da auch kein Problem machen.
Das einzige Problem das ich bisher mal hatte, war das nicht funktionieren von Composer, da sämtliche Methoden und Fallback Methoden die Composer nutzt gesperrt waren. Der Workaround war in dem Fall den vendors Ordner per Hand hoch zu laden. Da Composer immer verbreiteter wird, sollte sich das aber auf dauer nicht das Problem sein. Zudem bieten inzwischen manche Provider einen vorinstallierten Composer an.

Daß Zahlungs- und Versandmodule sowie das order_total-Modul ein "pain in the ar..." sind, ist bekannt aber eben nur konsequent zu ändern wenn man Punkt 1. über Bord wirft und grundsätzlich neu denkt.

Bei den Zahlungsmodulen gäbe es eine gute Lösung, wenn man bereit ist neu zu denken.
http://payum.forma-dev.com/documentation/0.9/Core/supported-payments
Wenn man das integriert, hat man auf sauberem Weg schon mal die Unterstützung für diverse Payment Anbieter.
Da z.B. Sylius das auch nutzt, würde man automatisch die Unterstützung für weitere Anbieter bekommen, wenn diese für Sylius umgesetzt werden.

[ShopNix]

Zunächst mal ganz allgemein:

Jedes Fremdprodukt, das in eine Software einfließt, macht es abhängig, und zwar auf Jahre hinaus.

Deshalb, aber auch, wie noRiddle treffend anmerkte, wegen des Ballasts, bin ich kein großer Freund irgendeines Frameworks.

Kompatibilität zu alten Modulen ist sicher eine feine Sache, wenn ich die allerdings zum Primärziel mache, muss ich auf lange Sicht gesehen ein totes Pferd reiten.

Wenn wir mal ehrlich sind: ein alter Klepper ist Modified schon heute.

Andererseits macht gerade der Verzicht auf Frameworks und  die prozedurale Programmierung Modified zum Rennpferd im Vergleich zur Konkurrenz.

Man könnte jetzt eine Grundsatzdiskussion über Sinn und Unsinn der OO-Programmierung anfangen, das liegt mir fern. Ich für mein Teil bin zu folgender Erkenntnis gelangt:

Objekte können eine ideale Ergänzung sein, aber die Welt besteht nicht nur aus Objekten, sondern auch aus Vorgängen. Ineffektiv wird die Programmierung, wenn sie Objekte in Prozeduren pressen will, aber auch, wenn sie Prozeduren in Objekte quetscht.

Wer's nicht glauben will, vergleiche die Performance konsequenter OO-Shops mit Modified oder noch besser: mit osCommerce.

Insofern bin ich geneigt, etwas wie "hybride Programmierung" zu favorisieren: Typische Objekte wie Artikel, Kunden, Warenkörbe sind als Objekte zu behandeln, typische Geschäftsprozesse sind (und bleiben) Prozeduren.

Als Ziel würde ich mir setzen, einen neuen Shop mit guter Performance, einem Minimum an Features, einem Minimum an Fremdprodukten und, das ist mir wichtig, einem absoluten Minimum an Admin-Funktionalität sowie ein Maximum an Schnittstelle zu WWS bzw ERP zu bieten. Es ist meiner Ansicht nach nicht sinnvoll, Auftragsbearbeitung, Bestellwesen, Lagerverwaltung, ... in einer Webumgebung zu machen.

Beginnen würde ich wie gesagt mit dem Datenmodell, indem ich die gewachsenen Möglichkeiten der Datenbank endlich einsetzen würde. Wir wollen bitte daran denken, dass unser Datenmodell aus einer Zeit stammt, in der MySQL noch keine Ahnung davon hatte, was referentielle Integrität ist. Leider ist (zumindest im Umfeld der Web-Programmierung) inzwischen eine ganze Generation von Programmierern herangewachsen, die kaum wissen werden, wovon ich rede.

Referentielle Integrität in der Datenbank bedeutet, dass mir die Datenbank einen Fehler um die Ohren haut, wenn ich z.B. versuche, einen Artikel zu löschen, der schon verkauft wurde.

Das klingt erst mal doof, bedeutet aber, dass niemand einen Artikel löschen kann, für den eine Auftrag vorliegt.

Diese (und weitere Geschichten) sind im Datenmodell zu implementieren, und deshalb ist und bleibt das Datenmodell das Fundament der ganzen Geschichte. Dort muss man anfangen.