Client/Server Architektur realisieren - Ideen

[Mavarik]

Zitat von DJ-SPM:

So. Ich werde definitiv eine Zwischenschicht einbauen. Es hat wirklich viele Vorteile. Sie wird höchstwahrscheinlich in PHP erstellt, also eine REST-API. Passt auch gut, da ich eine solche schon mehrfach umgesetzt habe.

...

Mir geht es hauptsächlich darum, ob die Kommandos in der o.g. Form eine gute Idee sind, oder ob ich ein anderes System/Format nutzen sollte. Dieser String könnte auch durchaus anders aussehen, z.B. so: "/user/registerOnline/192.168.1.6".
Oder man sendet gleich ein Record bzw. json-array. Es ist halt erstmal das Problem da, dass nicht absehbar ist, wie viele Parameter übergeben werden müssen, geschweige denn ganze ObjectLists.

Wie sieht dann Dein Daten-Flow aus...

1. Optimierte Routine in Deiner Anwendung.
2. Umsetzen/Parsen in einen String.
3. String wieder als Bytes per TCP senden
4. Bytes wieder in String konvertieren
5. String auseinander nehmen
6. Routine um aus dem String eine Anfrage zu kodieren
7. Umsetzen in JSON
8. Anfrage an PHP (oh grusel)
9. PHP Interpretiert die JSON Anfrage
10. Wieder SQL daraus machen
11. Am Server per TCP anfragen

Und dann das ganze wieder zurück?

Sehen wir mal von meine Abneigung zu PHP ab... Stringanalysen sind immer langsam und Du hast zu viele Konvertierungen.
SQL ist mir schon nicht kompakt genug... Also Übertragungen und Kommandos so knapp wie möglich halten... Besonders wenn Du diese sowieso
per TCP Übertragen willst.

Absender, Kommando, SeekNr, DatenbankID sind bei mir 7 Byte... Wenn man jetzt noch die MTU und ggf. noch für das P2P Protokoll die Daten berücksichtig, ergeben sind 1452 Bytes für Nutzer Daten.
Das ist meine Größe für eine optimale Datenübertragung von mehreren Kommandos...
Aber vielleicht optimiere ich an dieser Stelle auf ein bisschen weit...
Also vergiss den Absatz.

Mavarik

[p80286]

Zitat von Mavarik:

Endlich nicht mehr im Source ein feste Verknüpfung zu "der" Datenbank oder "der" Datenbankkomponente.

DAS soll der Sinn einer "Zwischenschicht" sein?
Eine "feste" Verbindung zur Datenbank in einer Anwendung?
Das scheint mir genauso sinnvoll wie hart kodierte Dateinamen.

Gruß
K-H

[Sir Rufo]

Zitat von p80286:

Zitat von Mavarik:

Endlich nicht mehr im Source ein feste Verknüpfung zu "der" Datenbank oder "der" Datenbankkomponente.

DAS soll der Sinn einer "Zwischenschicht" sein?
Eine "feste" Verbindung zur Datenbank in einer Anwendung?
Das scheint mir genauso sinnvoll wie hart kodierte Dateinamen.

Gruß
K-H

Nein, nicht nur aber eben auch. Es wird entkoppelt und man hat damit weniger Abhängigkeiten (z.B. von der Datenbank-Komponente Fröhlichsein mit Fluxkompensator und Ventilator, aber nur bei linksdrehendem Joghurt).

[Mavarik]

Zitat von p80286:

Zitat von Mavarik:

Endlich nicht mehr im Source ein feste Verknüpfung zu "der" Datenbank oder "der" Datenbankkomponente.

DAS soll der Sinn einer "Zwischenschicht" sein?
Eine "feste" Verbindung zur Datenbank in einer Anwendung?
Das scheint mir genauso sinnvoll wie hart kodierte Dateinamen.

Gruß
K-H

hmm eigentlich hatte ich

Zitat von Mavarik:

Endlich nicht mehr...

Geschrieben...