Javabasiertes Forum Schichtenarchitektur?

SlaterB · 20. Februar 2015 um 03:23

[abgespalten aus http://forum.byte-welt.net/byte-welt-projekte-projects/allgemeines-zu-projekten-generals/15212-javabasiertes-forum.html ]

ich rege auch einen Focus auf Unabhängigkeit/ Schichtensystem an:

Präsentationsschicht: das Web-Framework hat nur zunächst die Aufgabe, die Aktionen zu bestimmen und neuen User-Input in serverseite Objekte zu organisieren,
darunter: dann geht es in eine allgemeine Verarbeitungsschicht nur aus eigenen Klassen, die mit jedem Framework oder auch (gut für lokales Testen!) Desktop-GUI läuft
darunter: das innere System liefert eine abstrakt Ergebnisentscheidung, was anzuzeigen ist + alle variablen Daten dazu in eigenen Klassen
die Präsentationsschicht wiederum zeigt das ganze in irgendeiner selbstgewählten HTML-Seite an oder auch in Desktop-GUI

das Kernsystem könnte man also auch erstmal lange ohne Webserver in GUI programmieren
unabhängig zusätzlich J2EE-Zugang, Play-Zugang usw., beliebiges anschließbar

wähle also beliebig dein Framework, aber wäre schön darauf zu achten dass alles auch so läuft,
dass man das interne Konglomorat (aus laufenden User-Sessions, Application-Session, Verwaltung der laufenden DB, Logs, Überwachungs-Threads) usw. genauso für eine GUI hochfahren und nutzen kann,

nicht unbedingt gleich mehrere Clients die gleichzeitig mit einem laufenden Forum-Kern interagieren können, obwohl später ganz nett,
aber zumindest die Klassen jeweils zu übernehmen, in eigener Instanz zu verwenden,

das bedeutet auch, das User-Sessions, Formular-Daten usw. eigene Klassen sind, nicht zu sehr in ‚Lifecycle‘ von irgendwelchen Frameworks eingebunden,
vielleicht noch innerhalb der Präsentationsschicht, aber bei Übergabe nach unten ein Schnitt, wie Aufrufe an fernen Webservice/ RMI denken

vom MVC in ‚Spring MVC‘ bleibt dann vielleicht nicht mehr so viel übrig, aber abzuwarten,
grundsätzlich akzeptable Richtung?

Landei · 20. Februar 2015 um 04:29

ich rege auch einen Focus auf Unabhängigkeit/ Schichtensystem an:

Präsentationsschicht: das Web-Framework hat nur zunächst die Aufgabe, die Aktionen zu bestimmen und neuen User-Input in serverseite Objekte zu organisieren,

darunter: dann geht es in eine allgemeine Verarbeitungsschicht nur aus eigenen Klassen, die mit jedem Framework oder auch (gut für lokales Testen!) Desktop-GUI läuft

darunter: das innere System liefert eine abstrakt Ergebnisentscheidung, was anzuzeigen ist + alle variablen Daten dazu in eigenen Klassen

die Präsentationsschicht wiederum zeigt das ganze in irgendeiner selbstgewählten HTML-Seite an oder auch in Desktop-GUI

das Kernsystem könnte man also auch erstmal lange ohne Webserver in GUI programmieren
unabhängig zusätzlich J2EE-Zugang, Play-Zugang usw., beliebiges anschließbar

Ich denke, das ist Overkill. Insbesondere dürfte es schwer sein, davon zu abstrahieren, dass da eine Web-Anwendung läuft. Sicher ist das möglich, aber ich denke, dass zuviel Schichten und Abstraktionen eine Menge Performance fressen werden.

wähle also beliebig dein Framework, aber wäre schön darauf zu achten dass alles auch so läuft,
dass man das interne Konglomorat (aus laufenden User-Sessions, Application-Session, Verwaltung der laufenden DB, Logs, Überwachungs-Threads) usw. genauso für eine GUI hochfahren und nutzen kann,

Wieso? Ist es nicht wichtiger, dass man die Weboberfläche so leicht und schnell hochfahren kann, als wäre es eine Desktop-GUI?

nicht unbedingt gleich mehrere Clients die gleichzeitig mit einem laufenden Forum-Kern interagieren können, obwohl später ganz nett,
aber zumindest die Klassen jeweils zu übernehmen, in eigener Instanz zu verwenden,

das bedeutet auch, das User-Sessions, Formular-Daten usw. eigene Klassen sind, nicht zu sehr in ‚Lifecycle‘ von irgendwelchen Frameworks eingebunden,
vielleicht noch innerhalb der Präsentationsschicht, aber bei Übergabe nach unten ein Schnitt, wie Aufrufe an fernen Webservice/ RMI denken

vom MVC in ‚Spring MVC‘ bleibt dann vielleicht nicht mehr so viel übrig, aber abzuwarten,
grundsätzlich akzeptable Richtung?

Insgesamt möglich und in vielen Fällen sinnvoll, aber hier - meiner Meinung nach - zu heavy.

*** Edit ***

Sieht nicht so aus, als ob man da selbst viel ändern könnte, und egal wie gut eine fertige Lösung ist, gibt es immer Änderungswünsche.

SlaterB · 20. Februar 2015 um 04:49

[quote=Landei]

wähle also beliebig dein Framework, aber wäre schön darauf zu achten dass alles auch so läuft,
dass man das interne Konglomorat (aus laufenden User-Sessions, Application-Session, Verwaltung der laufenden DB, Logs, Überwachungs-Threads) usw. genauso für eine GUI hochfahren und nutzen kann,

Wieso? Ist es nicht wichtiger, dass man die Weboberfläche so leicht und schnell hochfahren kann, als wäre es eine Desktop-GUI?[/quote]
ich sehe nicht das entweder/ oder zwischen Hochfahren und unabhängigen Zugriff,
heißt ja nicht dass das ‚interne Konglomorat‘ (IK) separat zu starten ist, obwohl auch eine nette Option, sondern dass die Klassen und Abläufe dieselben sind, die auch in einer GUI verwendet werden können:
5 sec passiert nix, dann kommt ein Posting-Objekt zu User X, das IK schaut ob dieser User eingeloggt ist, ob eine gewisse Session besteht, ob er im entsprechenden Thread posten kann,
nach zig Schritten persistiert der Server evtl. das Posting und empfiehlt zur Anzeige den Thread inklusive neuen Posting usw. oder Fehlermeldung zurück,

für diesen Vorgang sollte es ziemlich egal sein, ob der Request von einem 10.000 km entfernen Browser übers Internet kam
oder von einem ActionListener einer GUI, bei der sowieso nur ein User eingeloggt sein kann,

all die internen Klassen, IK, sind dieselben, nicht doppelt zu programmieren oder überall etwas anzupassen je nach Schicht darüber, das wäre doch unschön

Nebenaussichten, die ich noch nicht genannt hatte:

statt Browser später auch Java-GUI bei Clients möglich für vollständige Forum-Nutzung, über RMI & Co.,
ginge strenggenommen natürlich auch für beliebige Webseiten, auch das aktuelle Forum, wenn man alles über HTTP steuern würde
das System kann in Teilen als Backoffice evtl. auch mit einem laufenden Forum, mit der DB zusammenarbeiten

hast du ein Beispiel für die Schwierigkeit, ‚zu abstrahieren, dass eine Web-Anwendung läuft‘?
eine träge Swing-GUI mit Buttons zum Wechsel und Events aus ActionListenern & Co. fand ich schon immer vergleichbar

gerade wenn minimalistisch sauber strukturiert würde es der Übersichtlichkeit arg helfen genaue Meilensteine/ Übergaben in der Verarbeitung einzurichten,
Interface, Trennung & Co., einfache Komponenten und Plugins die nur von Konzepten wie einer Posting-Klasse abhängen,
statt nur ein framework-web-abhängiger Lifecylce-Session-Mischmasch

Performance-Probleme sehe ich in Java, in GUIs die 99% ihrer Zeit auf Events/ Web-Requests warten gar nicht,

und überall in Java werden so viele Objekte erzeugt, Methoden aufgerufen, allein schon für jeden einzelnen String,
dass ein bisschen Meta-Kontrolle, von Request-Parameter auf ein interes Datenobjekt zu wechseln, nicht viel ausmacht

wieviele Postings soll es am Tag geben dass da etwas zusammenkommt?
und wenn dann wäre es geradezu ein Glücksfall falls je soviel Interesse/ Erfolg kommt

schließlich gilt noch die allgemeine Grundregel, doch nicht zu früh zu optimieren, Performance über sauberen Aufbau?
andere Gründe ok, falls es webframework-mäßig gar nicht zu handeln ist (Beispiele wären nett)

für mich ein ziemlich wichtiger Punkt, aber bevor es gar nichts gibt muss man eigentlich auch nicht streiten, später noch evtl. zu überlegen,
nur schon mal Gedanke ausgegraben

Landei · 20. Februar 2015 um 05:10

Ich denke, wir werden uns hier philosophisch nicht so schnell einigen.

Ich denke, Layer, Abstraktionen, Abhängigkeiten u.s.w. sollte man nur einführen, wenn man sie wirklich braucht (YAGNI). Dabei will ich hier kein Cowboy-Programming propagieren, sondern im Gegenteil jede Menge freiwillige Disziplin einfordern - ohne dass sie durch ein Framework erzwungen wird (was sowieso nicht funktioniert). Gerade bei so einem “größenwahnsinnigen” Projekt tut man gut daran, Pragmatismus und Minimalismus zu kultivieren.

Wie angekündigt, werde ich mal einen ganz einfachen Prototypen coden. Leider wird das nichts vor meinem Urlaub, also wenn alles klappt vielleicht Ende März. Wenn du bis dahin auch etwas Code hättest, um deinen Ideen etwas Fleisch zu geben, wäre das ein interessanter Vergleich.

SlaterB · 20. Februar 2015 um 05:51

genau, wenn man erst Code sieht, kann man an Beispielen zeigen, was besser allgemein zu bauen ist

ich glaube meine Idee ist dabei ziemlich klar: aus einer GUI-Maske kommt ein simpler Text,
Aufruf im Listener

int userId = aus irgendeiner Zustandsklasse holen;
String text = getTextField().getText();
Posting p = new Posting(userId, text, ..);
getForumEngine().post(p);

oder ein HttpReqest kommt an, get-Methode

int userId = param/cookie-Userirgendwoher holen;
String text = getParameter("text");
Posting p = new Posting(userId, text, ..);
getForumEngine().post(p);

wichtig ist dabei eine völlig freie Posting-Klasse,
die nicht von @ManagedBean-Annotations oder sonstigen Framework-Kram belastet ist, keine unbekannte Basisklasse,
kein Dependency Injection der Framework-Session, kein Anbinden an Darstellungs-XML-Primefaces Tree oder was immer es alles so gibt,

innerhalb der Präsentationsschicht ok, da darf es separat PostingBean geben, genau wie im GUI-Fall TextFelder, Listener, AWT-Thread und alles drum und dran,
aber an der Stelle, an der es zur Sache geht, muss es eine saubere unabhängige Klasse IK/ ForumEngine geben,
eine saubere Posting-Klasse nur mit den benötigten Infos UserId, Text usw.

und innerhalb der post-Methode ist es zu nahe 100% der gleiche Ablauf,
die Rückgaben auch nicht darauf ausgelegt, wie es angezeigt wird, allgemeine Enum der Zielseite, allgemeine Fehlermeldung/ Kategorie,

vorherige Eingabedaten zur Korrektur zurückliefern falls angebracht,
auch wenn sie in einer GUI vielleicht noch in den Textfeldern stehen, das weiß das interne System gar nicht,
die Präsentationsschicht entscheidet über die angezeigte Seite