Hallo 
Ich würde AJAX gerne irgendwie modular programmieren. Die Idee ist, dass ich mal ein so ein Modul je nach Anforderung dazugeben, oder weglasse. Z. B. mal arbeite ich mit retries, mal ohne retries.
Lt. Buch "Distributed Systems: Principles and Paradigms" (Kapitel 2) https://vowi.fsinf.at/wiki/Spezial:Materialien/TU_Wien:Verteilte_Systeme_VO_(Dustdar) gibt es folgende möglichen Client-Server-Architekturen:
- layered
- object-based
- data-centered
- event-based
layered:
Bei layered architecture wird ähnlich wie beim ISO OSI 7-Schichtenmodell ebenenweise gearbeitet. In jeder Ebene landet 1 Komponente. So eine Komponente könnte z. B. für Retries zuständig sein.
Dort könnte man vielleicht mit einem Stack arbeiten.
Allerdings scheint die Grunddefinition dieser Architektur so zu sein, dass ein Layer immer nur seinen darunterliegenden Layer aufrufen darf. Bei einem synchronen AJAX-Request wäre das kein Problem, bei einem asynchronen Request jedoch schon. Zitat aus dem Buch:
"The Basic idea for the layered style is simple: components are organized in a layered Fashion, where a component at layer L(i) is allowed to call components at the underlaying layer, but not the other way around".
object-based:
Hier gibt es zu jeder Komponente eine Klasse. Eine Klasse könnte z. B. für Retries zuständig sein.
Die Klassen müssen jedoch Beziehungen zueinander haben, denn sonst könnten sie sich nicht gegenseitig aufrufen.
Für synchrone Requests reicht es vermutlich, wenn die Beziehungen nur unidirektional sein, aber spätestens bei asynchronen Request müssen sie bidirektional sein. Bei einem AJAX-Request werden die Klasseninstanzen in der einen Richtung durchlaufen, beim asynchronen zugehörigen Response in der entgegengesetzten Richtung. Jede Klasse benötigt also einen predecessor (Vorgänger) und einen successor (Nachfolger).
Programmiert man objektorientiert, scheint mir das eine recht schöne Variante zu sein.
event-based:
Hier ist im Buch die Rede von "publish/subscribe Systems". Ich gehe davon aus, dass damit das Subject/Observer-Designpattern gemeint ist.
Es gibt also ein Subject, in dem sich ein Status ändern kann. Weiters ein Observer, der gerne über Statusänderungen benachrichtigt werden möchte.
Interessant wird diese Sache natürlich nur bei Responses asynchroner AJAX-Requests. Bei synchronen AJAX-Requests ist das uninteressant.
Fazit:
Da die Programmierung modular und universell verwendbar sein soll, also wahlweise synchrone und asynchrone Requests möglich sein sollen, denke ich, dass man bei AJAX 2 dieser Architekturen kombinieren muss:
- layered + event-based oder
- object-based + event-based
Jetzt würde mich interessieren, ob ihr euch auch schon mal Gedanken dazu gemacht habt, wie man das schön programmieren könnte. Wie würdet ihr das programmieren?
Ich würde AJAX gerne irgendwie modular programmieren. Die Idee ist, dass ich mal ein so ein Modul je nach Anforderung dazugeben, oder weglasse. Z. B. mal arbeite ich mit retries, mal ohne retries.
Lt. Buch "Distributed Systems: Principles and Paradigms" (Kapitel 2) https://vowi.fsinf.at/wiki/Spezial:Materialien/TU_Wien:Verteilte_Systeme_VO_(Dustdar) gibt es folgende möglichen Client-Server-Architekturen:
- layered
- object-based
- data-centered
- event-based
layered:
Bei layered architecture wird ähnlich wie beim ISO OSI 7-Schichtenmodell ebenenweise gearbeitet. In jeder Ebene landet 1 Komponente. So eine Komponente könnte z. B. für Retries zuständig sein.
Dort könnte man vielleicht mit einem Stack arbeiten.
Allerdings scheint die Grunddefinition dieser Architektur so zu sein, dass ein Layer immer nur seinen darunterliegenden Layer aufrufen darf. Bei einem synchronen AJAX-Request wäre das kein Problem, bei einem asynchronen Request jedoch schon. Zitat aus dem Buch:
"The Basic idea for the layered style is simple: components are organized in a layered Fashion, where a component at layer L(i) is allowed to call components at the underlaying layer, but not the other way around".
object-based:
Hier gibt es zu jeder Komponente eine Klasse. Eine Klasse könnte z. B. für Retries zuständig sein.
Die Klassen müssen jedoch Beziehungen zueinander haben, denn sonst könnten sie sich nicht gegenseitig aufrufen.
Für synchrone Requests reicht es vermutlich, wenn die Beziehungen nur unidirektional sein, aber spätestens bei asynchronen Request müssen sie bidirektional sein. Bei einem AJAX-Request werden die Klasseninstanzen in der einen Richtung durchlaufen, beim asynchronen zugehörigen Response in der entgegengesetzten Richtung. Jede Klasse benötigt also einen predecessor (Vorgänger) und einen successor (Nachfolger).
Programmiert man objektorientiert, scheint mir das eine recht schöne Variante zu sein.
event-based:
Hier ist im Buch die Rede von "publish/subscribe Systems". Ich gehe davon aus, dass damit das Subject/Observer-Designpattern gemeint ist.
Es gibt also ein Subject, in dem sich ein Status ändern kann. Weiters ein Observer, der gerne über Statusänderungen benachrichtigt werden möchte.
Interessant wird diese Sache natürlich nur bei Responses asynchroner AJAX-Requests. Bei synchronen AJAX-Requests ist das uninteressant.
Fazit:
Da die Programmierung modular und universell verwendbar sein soll, also wahlweise synchrone und asynchrone Requests möglich sein sollen, denke ich, dass man bei AJAX 2 dieser Architekturen kombinieren muss:
- layered + event-based oder
- object-based + event-based
Jetzt würde mich interessieren, ob ihr euch auch schon mal Gedanken dazu gemacht habt, wie man das schön programmieren könnte. Wie würdet ihr das programmieren?
