Hi zusammen,
ich schreibe zur Zeit meine erste Webanwendung mit JSF, nebenbei lese ich immer wieder mal Artikel über Seam.
Wenn ich das richtig verstanden habe, kann ich in Seam ja direkt auf die Anwendungslogik zugreifen. D.h. ich habe keine extra JSF-Bean, deren Methoden ich aufrufen kann, sondern ich kann direkt auf Session Beans zugreifen.
D.h. ich habe zum Beispiele eine Session Bean mit der Methode createUser() und als Rückgabewert einen String, wie man es von JSF ja kennt. Der String dient dann für die Entscheidung zu welcher Seite als nächstes gewechselt werden soll.
Ansonsten müsste ich in einer JSF-Bean zunächst die Session Bean aufrufen und dann den String zurückgeben, was ich persönlich nun nicht so schlimm finde. Aber vielleicht liegt das auch an meinen kleinen Projekten. Bei größeren Projekten hat man sicher eine Vielzahl von quasi Wrapper-Methoden.
Zu meiner Frage: Kann mir das mit den String eventuell zum Verhängnis werden? Ich vermische ja quasi GUI-Logik mit Anwendungslogik. In einem Artikel über Seam heißt es, dass man hier die 3-Schichtenarchitektur vermischt, weil man die Anwendungslogik stark an die GUI bindet. Das heißt aber doch nur, dass externe Clients (z.B. Swing-Anwendung) die Strings auf ähnliche Weise parsen muss, wie die GUI. Wo ist der Unterschied, ob ich nun Strings parse oder 0, 1, 2 als Rückgabewert bekomme?
Der Autor schlägt zusätzlich eine 4-Schichtenarchitektur vor, in der über der Kernlogik nochmal eine Adaptionsschicht für verschiedene Clients zum Einsatz kommt. Das verstehe ich nicht ganz. Dann bin ich doch genauso weit, wie vorher? Dann würde ich wieder von JSF aus die Adaptionsschicht aufrufen, irgendeine JSF-Bean und diese würde die Kernlogik aufrufen. Wo habe ich dann mit Seam noch etwas gewonnen?
Gruß
Mike
ich schreibe zur Zeit meine erste Webanwendung mit JSF, nebenbei lese ich immer wieder mal Artikel über Seam.
Wenn ich das richtig verstanden habe, kann ich in Seam ja direkt auf die Anwendungslogik zugreifen. D.h. ich habe keine extra JSF-Bean, deren Methoden ich aufrufen kann, sondern ich kann direkt auf Session Beans zugreifen.
D.h. ich habe zum Beispiele eine Session Bean mit der Methode createUser() und als Rückgabewert einen String, wie man es von JSF ja kennt. Der String dient dann für die Entscheidung zu welcher Seite als nächstes gewechselt werden soll.
Ansonsten müsste ich in einer JSF-Bean zunächst die Session Bean aufrufen und dann den String zurückgeben, was ich persönlich nun nicht so schlimm finde. Aber vielleicht liegt das auch an meinen kleinen Projekten. Bei größeren Projekten hat man sicher eine Vielzahl von quasi Wrapper-Methoden.
Zu meiner Frage: Kann mir das mit den String eventuell zum Verhängnis werden? Ich vermische ja quasi GUI-Logik mit Anwendungslogik. In einem Artikel über Seam heißt es, dass man hier die 3-Schichtenarchitektur vermischt, weil man die Anwendungslogik stark an die GUI bindet. Das heißt aber doch nur, dass externe Clients (z.B. Swing-Anwendung) die Strings auf ähnliche Weise parsen muss, wie die GUI. Wo ist der Unterschied, ob ich nun Strings parse oder 0, 1, 2 als Rückgabewert bekomme?
Der Autor schlägt zusätzlich eine 4-Schichtenarchitektur vor, in der über der Kernlogik nochmal eine Adaptionsschicht für verschiedene Clients zum Einsatz kommt. Das verstehe ich nicht ganz. Dann bin ich doch genauso weit, wie vorher? Dann würde ich wieder von JSF aus die Adaptionsschicht aufrufen, irgendeine JSF-Bean und diese würde die Kernlogik aufrufen. Wo habe ich dann mit Seam noch etwas gewonnen?
Gruß
Mike
