Quali sono i vantaggi e gli svantaggi del modello Session Façade Core J2EE?

Question

Quali sono i vantaggi e gli svantaggi del modello Session Façade Core J2EE?

Quali sono le ipotesi alla base?

Queste ipotesi sono valide in un particolare ambiente?

Answer 1

Session Facade è un modello fantastico: in realtà è una versione specifica del modello Business Facade.L'idea è di raggruppare le funzionalità aziendali in pacchetti distinti, come TransferMoney(), Withdraw(), Deposit()...In modo che il tuo codice dell'interfaccia utente acceda alle cose in termini di operazioni aziendali invece di accesso ai dati di basso livello o altri dettagli di cui non dovrebbe preoccuparsi.

Nello specifico con la Session Facade - usi un Session EJB per fungere da facciata aziendale - il che è carino perché puoi sfruttare tutti i servizi J2EE (autenticazione/autorizzazione, transazioni, ecc.)...

Spero che aiuti...

Answer 2

Il vantaggio principale del modello Session Facade è che è possibile suddividere un'applicazione J2EE in gruppi logici in base alla funzionalità aziendale.Una Session Facade verrà chiamata da un POJO dall'interfaccia utente (ad es.un delegato aziendale) e avere riferimenti agli oggetti di accesso ai dati appropriati.Per esempio.una PersonSessionFacade verrebbe chiamata da PersonBusinessDelegate e quindi potrebbe chiamare PersonDAO.I metodi su PersonSessionFacade seguiranno, come minimo, il modello CRUD (Create, Retrieve, Update ed Elimina).

In genere, la maggior parte delle Session Facade sono implementate come EJB di sessione senza stato.Oppure, se ti trovi a Spring Land e utilizzi AOP per le transazioni, puoi creare un servizio POJO che può essere tutti i punti di unione per il tuo gestore delle transazioni.

Un altro vantaggio del modello SessionFacade è che qualsiasi sviluppatore J2EE con un minimo di esperienza ti capirà immediatamente.

Svantaggi del modello SessionFacade:presuppone un'architettura aziendale specifica che è vincolata dai limiti della specifica J2EE 1.4 (vedere i libri di Rod Johnson per queste critiche).Lo svantaggio più dannoso è che è più complicato del necessario.Nella maggior parte delle imprese ragnatela applicazioni, avrai bisogno di un contenitore servlet e la maggior parte dello stress in un'applicazione Web sarà al livello che gestisce HttpRequest o l'accesso al database.Di conseguenza, non sembra utile distribuire il contenitore servlet in uno spazio di processo separato dal contenitore EJB.Cioè.le chiamate remote agli EJB creano più problemi che guadagni.

Answer 3

Rod Johnson afferma che il motivo principale per cui vorresti utilizzare una Session Facade è se stai eseguendo transazioni gestite da contenitori, che non sono necessarie con framework più moderni (come Spring).

Dice che se hai una logica aziendale, inseriscila nel POJO.(Con cui sono d'accordo - penso che sia un approccio più orientato agli oggetti - piuttosto che implementare una sessione EJB.)http://forum.springframework.org/showthread.php?t=18155

Felice di sentire argomenti contrastanti.

Answer 4

Sembra che ogni volta che si parla di qualsiasi cosa relativa a J2EE ci siano sempre un sacco di ipotesi dietro le quinte - che le persone danno per scontato in un modo o nell'altro - che poi portano alla confusione.(Probabilmente avrei potuto anche rendere la domanda più chiara.)

Supponendo (a) di voler utilizzare transazioni gestite dal contenitore in senso stretto attraverso la specifica EJB

Le facciate di sessione sono una buona idea, perché astraggono le transazioni del database di basso livello per essere in grado di fornire una gestione delle transazioni delle applicazioni di livello superiore.

Supponendo (b) che tu intenda il concetto architettonico generale della facciata della sessione - allora

Disaccoppiare servizi e consumatori e fornire un'interfaccia amichevole oltre a tutto ciò è una buona idea.L'informatica ha risolto molti problemi "aggiungendo un ulteriore livello di indirettezza".

Rod Johnson scrive "Gli SLSB con interfacce remote forniscono un'ottima soluzione per le applicazioni distribuite costruite su RMI.Si tratta tuttavia di un requisito minoritario.L'esperienza ha dimostrato che non vogliamo utilizzare un'architettura distribuita a meno che non siamo costretti a farlo dai requisiti.Possiamo comunque servire client remoti, se necessario, implementando una facciata remota sopra un buon modello di oggetti co-localizzati." (Johnson, R "J2EE Development without EJB" p119.)

Supponendo (c) che si consideri la specifica EJB (e in particolare il componente della facciata della sessione) come una rovina nel panorama del buon design, allora:

Rod Johnson scrive "In generale, non ci sono molti motivi per cui si useresti uno SLSB locale in un'applicazione di primavera, poiché Spring fornisce una gestione delle transazioni dichiarative più capace di EJB e CMT è normalmente la motivazione principale per l'uso di SLSB locali.Quindi potresti non aver bisogno del livello EJB." http://forum.springframework.org/showthread.php?t=18155

In un ambiente in cui le prestazioni e la scalabilità del server web sono le preoccupazioni principali - e il costo è un problema - allora l'architettura della facciata della sessione sembra meno attraente - può essere più semplice parlare direttamente con il database (anche se si tratta più di una questione di livelli).