Was sind die Vorteile und Nachteile des Session Fassade Core J2EE Pattern?

Den wichtigsten Vorteil des Session Facade Muster ist, dass Sie sich aufteilen, um eine J2EE-Anwendung in logische Gruppen von business-Funktionalität. Eine Session-Fassade wird durch eine POJO-von der Benutzeroberfläche (z.B. Business Delegate), und Verweise auf entsprechende Data-Access-Objekte. E. g. ein PersonSessionFacade aufgerufen werden würde, indem die PersonBusinessDelegate und dann konnte es aufrufen, die das interface PersonDAO. Die Methoden, die auf der PersonSessionFacade werden, zumindest die Folgen, die CRUD-Muster (Create, Retrieve, Update und Delete).

In der Regel, die meisten Session-Fassaden sind implementiert als stateless session EJBs. Oder wenn Sie im Frühjahr land mit AOP für Transaktionen, können Sie erstellen eine service-POJO, dass die alle die join-Punkte für Ihre Transaktions-manager.

Ein weiterer Vorteil der SessionFacade Muster ist, dass alle J2EE-Entwickler mit einem Minimum an Erfahrung wird sofort verstehen, Sie.

Nachteile der SessionFacade Muster: er nimmt eine bestimmte enterprise-Architektur, ist eingeschränkt durch die Grenzen der J2EE 1.4-Spezifikation (siehe Rod Johnson Bücher für diese Kritik). Die meisten schädlichen Nachteil ist, dass es ist komplizierter als nötig. In den meisten Unternehmen web - Anwendungen brauchen Sie einen servlet-container, und die meisten der stress in einer web-Anwendung werden auf der Stufe, die Griffe HttpRequests oder Datenbank-Zugriff. Folglich, es scheint nicht, lohnt sich das bereitstellen der servlet-container in einem separaten Prozess, Adressraum, von dem EJB-container. I. e. remote-Aufrufe an EJBs erstellen mehr Schmerzen als Gewinn.

Es scheint, dass, wenn Sie über alles reden J2EE-verwandten - es gibt immer eine ganze Reihe von Annahmen, die hinter den kulissen - die Leute annehmen, die eine oder andere Weise - das führt dann zu Verwirrung. (Habe ich wohl gemacht haben könnte, die Frage klarer zu.)

Vorausgesetzt, (a) wollen wir mit container-verwalteten Transaktionen in einem strengen Sinn durch die EJB-Spezifikation dann

Sitzung Fassaden sind eine gute Idee - denn Sie abstrahieren low-level-Datenbank-Transaktionen zur Verfügung stellen zu können higher-level application transaction management.

Unter der Annahme, (b) dass Sie meinen, die Allgemeine architektonische Konzept des session-Fassade - dann

Entkopplung von services und Verbraucher und bietet eine benutzerfreundliche Oberfläche, über die Oberseite des das ist eine gute Idee. Die informatik hat sich gelöst, viele Probleme, die durch 'hinzufügen eine zusätzliche Schicht der Dereferenzierung'.

Rod Johnson schreibt "SLSBs mit remote-Schnittstellen sorgen für eine sehr gute Lösung für verteilte Anwendungen, die über RMI. Dies ist jedoch eine Minderheit Anforderung. Die Erfahrung hat gezeigt, dass wir nicht wollen, um mit verteilten Architektur, es sei denn gezwungen, zu den Anforderungen. Wir können noch service-remote-clients, falls erforderlich, durch Implementierung eines remoting-Fassade auf der Spitze eines guten co-Lage-Objekt-Modell." (Johnson, R "J2EE-Entwicklung ohne EJB" p119.)

Unter der Annahme, (c), sollten Sie die EJB-Spezifikation (und insbesondere die session-Fassade-Komponente) zu einem Schandfleck für die Landschaft von gutem design dann:

Rod Johnson schreibt
"Im Allgemeinen gibt es nicht viele Gründe, die Sie verwenden würden, eine lokale SLSB an alle, die in einer Spring-Anwendung, als der Frühling bietet mehr fähig deklarativen Transaktions-management als EJB und CMT ist normalerweise die wichtigste motivation für die Verwendung von lokalen SLSBs. So können Sie nicht brauchen, th EJB-Schicht überhaupt. "http://forum.springframework.org/showthread.php?t=18155

In einer Umgebung, wo die Leistung und Skalierbarkeit der web-server sind die wichtigsten Anliegen - und die Kosten ein Problem ist -, dann wird die session Fassade Architektur sieht weniger attraktiv - es kann einfacher sein, zu sprechen direkt in die Datenbank einzutragen (obwohl dies mehr über tiering.)