modified 3.0 - wie geht es weiter?

[webald]

ich weiss, 2.0 ist noch nicht mal veröffentlicht und ich will hier gleich die Versionen 2.01 und 2.1 überspringen. die Version 2 wird eine Anpassung von 1.x sein, d. h. einzelne neue Module enthalten, und auch wieder weitere bestehende Fehler behoben haben. Es wird aber keine (komplett) neue Technik und auch keine neue Struktur eingeführt.

Ich muss für uns ein paar Änderungen/Erweiterungen vornehmen und da stellt sich für mich die Frage nach dem wie.

Mein derzeitiger Ansatz wäre eine komplett neue Klassenstruktur (klar fange ich mit dem an was ich zuerst brauche), Datenzugriff mit PDO und parallel dazu Bereitstellung der Funktionen der Klasse als Webservice (SOAP, REST).

Mir persönlich geht es im Augenblick nur um die Datenmanipulation, nicht um die Darstellung (HTML 4/5). Da dürfen sich andere drum kümmern.

Man könnte dies parallel im Shop nutzen und ggf. bestehendes nach und nach auf eine solche Trennung umstellen.

Vorteil:
Zentrale Logik (ggf. sogar Transaktionssicher)
Admin-Oberfläche separat erstellbar, über die gleichen Funktionen ließe sich ggf. die "Mini-Wawi" von noRiddle realisieren, ohne das der Shop selber betroffen wäre.
Darstellung, Template und Datenbank bleiben wie gehabt
andere Datenbank-Systeme möglich

Nachteil:
Neues Know-How nötig
höhere Mindestanforderung
Parallele Codepflege

Gibt es da Meinungen zu? Hinweise? Zukunftsträchtigere, modernere Lösungen?

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

[ShopNix]

Auweh. Du willst ein völlig neues System, ist Dir das eigentlich klar?

Mir schwant, Du wirst die nötigen Programmierkapazitäten nicht zusammenbringen.

Da ich selbst aus der ERP-Ecke stamme und daher die Unterschiede zwischen MySQL und "richtigen" Datenbanken recht gut kenne, vermute ich, dass Du schon beim Datenmodell (transaktionssicher, referentielle Integrität, etc ...) nicht viel Verständnis ernten wirst.

Es ist eigentlich traurig, dass die meisten Programmierer im Web-Umfeld einen ordentlichen Teil der Funktionalität "richtiger" Datenbanken nicht nutzen. Das liegt vermutlich in der Geschichte von MySQL und der Tatsache, dass MySQL gerade durch den Verzicht auf derartige Techniken mit minimaler Hardware rattenschnell ist.

Zu meiner Schande muß ich gestehen, dass ich zwar am Rande mitbekommen habe, dass MySQL in Hinsicht auf derartige Funktionalität aufgeholt hat, ich selbst mich allerdings nie um diese Möglichkeiten gekümmert habe. Liegt wahrscheinlich daran, dass ich dem Mainstream folgte.

Zum Punkt SOAP:
Für einen Kunden habe ich einen SOAP-Server entwickelt. Ich kann allerdings das Dingen nicht guten Gewissens veröffentlichen, weil wsdl und einige dazugehörige xml-Dateien nicht auf meinem Mist gewachsen sind. Die Vorgaben kamen vom ERP-Anbieter, der hat auch diese Dateien geliefert.

[webald]

Das die Änderungen massiv sind ist mir klar. Allerdings glaube ich, dass die Vorteile überwiegen. Und wie gesagt man kann das parallel betreiben, wie das in vielen anderen Systemen auch der Fall ist (Mir ist MS NAV als ERP vertraut und da konnte man in einer 2-Tier-Lösung und in einer 3-Tier-Lösung abeiten, gleichzeitig).

Ich glaube, dass viele User es nicht interessiert, wie die Daten in den Shop kommen und wieder zurück. Ist bei einem ERP nicht anders, da ist für den Power-User ja in aller Regel auch schon bei der Report-Erstelung Schluss. Den meisten wäre es am liebsten mit eine paar Funktionsaufrufen ein Ergebnis zu bekommen, ohne SQL überhaupt jemals angefasst zu haben. Dass aber setzt eine einheitliche Klassenstruktur voraus.

Geschwindigkeit müßtem man mal vergleichen, aber da muss ich die DB erst mal richtig mit Daten voll packen um eine verünftige Aussage zu erhalten. Aber wahrscheinlicher ist, dass die Bilder im Shop länger zum laden brauchen als die Datenabfrage über einen einheitlichen Layer.

Den SOAP Server brauchst Du nicht veröffentlichen. Den habe ich schon bzw. sind die Klassen ab 2.0 schon im Standard dabei (NuSOAP).

Ich werde das auf jeden Fall mal anfangen.

[ShopNix]

Mach hinne, aber beginne mit einem Redesign oder vielleicht sogar besser mit einem Neudesign der Datenbank unter Berücksichtigung der referentiellen Integrität.

Schau mal hier: http://www.peterkropff.de/site/mysql/referentielle_integritaet.htm

Es geht also inzwischen einiges, und wenn Du ernsthaft an die Sache herangehen willst, solltest Du zumindest in Deiner Entwicklungsumgebung diese Geschichten berücksichtigen. Eine sofortige Fehlermeldung von der Datenbank ist allemal besser, als nach Wochen zu versuchen, die Ursache einer fehlenden Abhängigkeit aufzufinden.

Bezüglich der Klassenstrukturen: Objektorientierte Programmierung ist natürlich ein wunderschönes Modewort. In der Praxis zeigt sich allerdings, dass Systeme wie Magento oder Oxid, die das konsequent umgesetzt haben, um mindestens einen Faktor 10 lahmer sind, als das gute alte osCommerce, das fast ausschließlich prozedural ist.

Schon die Trennung von Layout und Programm ist mit Vorsicht zu genießen, weil sich das zwar toll anhört, aber in der Praxis nicht so doll funktioniert. Will ich bei z.B. bei osCommerce ein zusätzliches Feld aus der Datenbank anzeigen, so füge ich das in die Datenbank ein und zeige es an. Fertig.

Das ist schon bei Modified mit mehr Aufwand verbunden, weil ich das Feld ebenfalls im Programm einbauen muss, dann an das Template übergeben und anschließend ins Template einbauen muss.

Bei Oxid ist es oft klüger, die Finger davon zu lassen und die Funktionalität gleich ins Template einzubauen, ggfls. durch Erstellung einer neuen Smarty-Funktion.

Mein Fazit: Wir haben in einem Shop Geschäftsprozesse, die prozedural ablaufen. Einzelne Objekte, wie z.B. der Warenkorb, haben durchaus ihre Berechtigung. Das Gesamtpaket mit Gewalt in eine Klassenstruktur zu packen, halte ich hingegen für groben Unfug.

Sollte es jemand fertigbringen, einen Shop mit ähnlichem Funktionsumfang und ähnlicher Performance vollständig objektorientiert zu erstellen, leiste ich selbstverständlich Abbitte.

[web4design]

Bezüglich der Klassenstrukturen: Objektorientierte Programmierung ist natürlich ein wunderschönes Modewort. In der Praxis zeigt sich allerdings, dass Systeme wie Magento oder Oxid, die das konsequent umgesetzt haben, um mindestens einen Faktor 10 lahmer sind, als das gute alte osCommerce, das fast ausschließlich prozedural ist.

Das hat aber garantiert nichts damit zu tun, dass die Klassen verwenden. Das Gesamtkonzept wird dann wohl eher nicht stimmen.

[ShopNix]

Wie gesagt:
Sollte es jemand fertigbringen, einen Shop mit ähnlichem Funktionsumfang und ähnlicher Performance vollständig objektorientiert zu erstellen, leiste ich selbstverständlich Abbitte.

Kannst Du einen schnellen Shop nennen, der vollständig objektorientiert programmiert ist?

[web4design]

Nein, kann ich nicht.

Aber nur weil ich keinen nennen kann und es vielleicht noch keinen gibt, hat es nichts mit Objektorientierung zu tun.

[ShopNix]

Die Worte hör' ich wohl, allein mir fehlt der Glaube!

[baalze]

Es lag wohl eher an der fehlenden Überlegung/Kenntnis, dass die Software-Architektur nicht objektorientiert entworfen wurde.
Einige Objekte zu erzeugen und viele mehr Funktionsaufrufe; ich würde nicht behaupten das schätzungsweise +50ms erheblich ist.

[hstreicher]

a) der Programmierer in mir sagt
Ja Komplettes Neudesign von der DB angefangen 
(und zu Shopnix ja das Objektzeugs kostet imho Zeit , wenn auch keinen Faktor 10)

b) der Kaufmann sagt
um OS/Commerce-XT-Commerce-Modified  hat sich so ein grosses Ökosystem an Modulen und Templates
aufgebaut , die man mit dem Neudesign nicht mehr nutzen kann deshalb würde ich es lassen würde
(oder nicht der Manpower vorhanden ist sie nachzubauen/anzupassen)

[ShopNix]

ja das Objektzeugs kostet imho Zeit , wenn auch keinen Faktor 10

Der Faktor 10 ist praktische Erfahrung mit den genannten Systemen. Ich habe einen größeren Kunden, der vor ca. 2 Jahren verschiedene Warenwirtschaftssysteme angetestet hat. Bei der Gelegenheit habe ich ihm jeweils den Shop installiert, zu dem eine Schnittstelle vorhanden war. Das war zunächst Magento, danach Oxid, beide in der Community-Edition.

Damit war das Datenvolumen vergleichbar, wenn ich auch sicher nicht die optimalen Bedingungen für Benchmarks geschaffen habe. Das ursprüngliche System war ein xt:Commerce, aus dem ja nun unser Modified hervorging.

Ich habe nicht ermittelt, ob das Problem an der objektorientierten Programmierung liegt oder andere Ursachen hat. Insofern kann ich keine Kausalität herstellen, sondern lediglich auf die Korrelation hinweisen. Wie bereits angemerkt: Sollte jemand ein System benennen, das konsequent mit OOP umgesetzt ist, und bei ähnlichem Funktionsumfang ähnlich performt, gehe ich ohne zu zögern nach Canossa.

Zum Ökosystem:
Das ist ein Argument, das nicht ganz von der Hand zu weisen ist. Andererseits hat natürlich auch ein Neudesign seinen Charme. So stoßen mir zum Beispiel immer wieder gewisse Schwächen in Zahlungs- Versand- und OrderTotalmodulen sauer auf. Da gerade Zahlungsdienstleister inzwischen Vollzug zurückmelden können, Versanddienstleister Paketverfolgung anbieten, dass eine Nachnahmegebühr über ein OrderTotal-Modul realisiert werden muß, ... da könnte man aus der Erfahrung heraus einiges verbessern. Das zieht natürlich einen Rattenschwanz hinterher, der nicht von schlechten Eltern ist.