Was sind die Vor- und Nachteile der Session Fassade Core-J2EE-Muster?

Question

Was sind die Vor- und Nachteile der Session Fassade Core-J2EE-Muster?

Was sind die Annahmen dahinter?

Sind diese Annahmen gültig in einer bestimmten Umgebung?

Answer 1

Session Facade ist ein fantastisches Muster - es ist wirklich eine spezielle Version des Business Fassadenmuster. Die Idee ist, Business-Funktionalität in einzelne Bündel zu binden - wie TransferMoney () zurückziehen (), Kaution () ... Damit Ihr UI-Code wird die Dinge in Bezug auf die Geschäftstätigkeit statt geringen Datenzugriff oder andere Details Zugriff dass es sollte nicht sein müssen besorgt.

Speziell mit der Session Fassade - Sie eine Session EJB verwenden als Business-Fassade zu handeln - die dann schöne Sache ist, dass Sie alle Vorteile des J2EE-Service (Authentifizierung / Autorisierung, Transaktionen, etc.) nehmen können ...

Ich hoffe, das hilft ...

Answer 2

Der Hauptvorteil des Session-Facade-Musters ist, dass Sie eine J2EE-Anwendung in logische Gruppen von Business-Funktionalität teilen können. Eine Session Fassade wird von einem POJO von der Benutzeroberfläche (das heißt ein Business-Delegierter) und haben Verweise auf geeignete Datenzugriffsobjekte aufgerufen werden. Z.B. ein PersonSessionFacade würde durch die PersonBusinessDelegate aufgerufen werden und dann könnte es die PersonDao nennen. Die Methoden, die auf dem PersonSessionFacade werden, zumindest, folgen Sie dem CRUD-Muster (Erstellen, Abrufen, Aktualisieren und Löschen).

Normalerweise sind die meisten Session Fassaden werden als Stateless Session EJBs umgesetzt. Oder wenn Sie im Frühjahr Land mit AOP für Transaktionen sind, können Sie einen Dienst POJO erstellen, die alle die Punkte für Ihre Transaktions-Manager beitreten werden kann.

Ein weiterer Vorteil des SessionFacade Musters ist, dass jeder J2EE Entwickler mit einem Minimum an Erfahrung wird sofort verstehen Sie.

Die Nachteile der SessionFacade Muster: Es nimmt eine spezifische Unternehmensarchitektur, die durch die Grenzen der J2EE 1.4-Spezifikation beschränkt ist (siehe Rod Johnson Bücher für diese Kritik). Die schädlichsten Nachteil ist, dass es komplizierter als nötig. In den meisten Unternehmen web Anwendungen benötigen Sie einen Servlet-Container, und die meisten der Stress in einer Web-Anwendung wird auf der Ebene sein, die HttpRequests oder Zugriff auf die Datenbank behandelt. Folglich ist es nicht der Mühe wert scheinen den Servlet-Container in einem separaten Prozess Raum vom EJB-Container zu implementieren. D. h Ferngespräche zu EJBs mehr Schmerzen als Verstärkung erstellen.

Answer 3

Rod Johnson behauptet, dass der Hauptgrund Sie eine Session Fassade verwenden wollen würde, wenn Sie Container verwaltet Transaktionen tun - (. Wie Spring), die mit moderneren Rahmen nicht notwendig sind,

Er sagt, dass, wenn Sie Business-Logik - es in der POJO setzen. (Was ich stimme - Ich denke, die ein objektorientierten Ansatz - und nicht eine Sitzung EJB implementiert.) http://forum.springframework.org/showthread.php?t=18155

Happy gegensätzliche Argumente zu hören.

Answer 4

Es scheint, dass, wenn Sie über alles reden J2EE in Verbindung stehend - es gibt immer eine ganze Reihe von Annahmen, die hinter den Kulissen - die Leute die eine oder die andere übernehmen - die dann zu Verwirrung führt. (Ich wahrscheinlich auch die Frage klarer gemacht haben könnte.)

Unter der Annahme (a) wir Container verwaltet Transaktionen im engeren Sinne durch die EJB-Spezifikation dann

verwenden möchten

Session Fassaden sind eine gute Idee - weil sie abstrakt die Low-Level-Datenbanktransaktionen entfernt Lage sein Management eine höhere Ebene Anwendungstransaktion

.

Unter der Annahme, (b), dass Sie das allgemeine architektonische Konzept der Sitzung Fassade bedeuten - dann

Die Entkoppelung Dienstleistungen und Verbraucher und eine benutzerfreundliche Oberfläche über die Spitze dieser Bereitstellung ist eine gute Idee. Informatik wurde von ‚Hinzufügen einer zusätzlichen Schicht von Dereferenzierung‘ viele Probleme gelöst.

Rod Johnson schreibt „SLSBs mit Remote-Schnittstellen eine sehr gute Lösung für verteilte Anwendungen über RMI gebaut bieten. Dies ist jedoch eine Minderheit Anforderung. Die Erfahrung hat gezeigt, dass wir nicht wollen, verteilte Architektur verwenden, es sei denn, durch Anforderungen gezwungen. wir können immer noch Remote-Clients bei Bedarf Service von einer Fassade Remoting auf einem guten co-located Objektmodell zu implementieren.“ (Johnson, R "J2EE-Entwicklung ohne EJB" p119).

Unter der Annahme, (c), dass Sie die EJB-Spezifikation (und insbesondere die Sitzung Fassade Komponente) betrachten eine Plage über die Landschaft von gutem Design sein, dann:

Rod Johnson schreibt „In der Regel gibt es nicht viele Gründe, warum Sie eine lokale SLSB überhaupt in einer Frühlings-Anwendung verwenden würden, als Frühling fähiges deklaratives Transaktionsmanagement als EJB bietet, und CMT ist in der Regel die Hauptmotivation für die lokale SLSBs verwenden. Damit Sie nicht benötigen th EJB-Schicht überhaupt nicht. " http://forum.springframework.org/showthread.php ? t = 18155

In einer Umgebung, in der Leistung und Skalierbarkeit des Web-Servers sind die wichtigsten Anliegen - und Kosten sind ein Problem - dann die Sitzung Fassade Architektur sieht weniger attraktiv - es kann einfacher sein, direkt mit dem datbase zu sprechen (auch wenn dies mehr über ist Tiering).