[Java EE - EJB3] ... i servizi della web application

[javacomelava]

Salve a tutti

Sto sviluppando una web application con la piattaforma java EE.L'archietettura è la seguente:

Presentation Layer: JSF
Business Layer: EJB + Spring
Persistence Layer: JPA

Il mio strato di dominio è composto da svariate entità,che sono state mappate con il database sottostante.

A livello persistenza i servizi sono offerti da apposte classi DAO,una per ogni entità che ho definito nel dominio:

Esempio:
Per l'entità FATTURA ho creato la classe FatturaDAO,che espone tutti i servizi di accesso ai dati che riguardano l'entità fattura ( inserisciFattura , eliminaFattura etc etc.)


A livello di business-logic ho deciso di implementare i servizi suddividendoli per in base ai ruoli con i quali è possibile accedere all'applicazione:

EJB : VenditoreIngrossoService

che esponde tutti i servizi dedicati a un venditore all'ingrosso.Questi servizi di "alto livello" espletano la loro funzione interfacciandosi con i vari DAO del livello sottostante.

I serivizi sono suddivisi in modo logico ? C'e' qualche aspetto che non ho valutato?

Mi piacerebbe sentire il parere di qualcuno con piu esperienza del sottoscritto....

[nuovoUtente86]

Sostanzialmente tu utilizzi nel layer di logica degli EJB facàde che incorporano diverse entità di persistenza ed è un approccio che francamente odio, anche se prestazionalmente può risultare migliori in alcune circostanze, quando ad esempio si opera su server distribuiti, al costo di appesantire il codice centralizzato.
Parlando invece del layer persistenza in sè, bisogna vedere se è veramente utile una gestione BMP quindi completamente programmatica, piuttosto che CMP quindi gestista dal container (parlando in termini familiari alla specifica 2).

[javacomelava]

E' proprio cosi'. Da quello che hai detto confermi i miei dubbi. In questo modo ho pochi service EJB (centralizzando il codice),ma ogni service è bello corposo a livello di codice.La mia principale paura è quella di avere problemi di performance e affidabilità del sistema nel caso in cui molti client si connettessero all'applicazione.

Per quanto riguarda lo strato di persistenza ho deciso di gestirla da me con le mie manine,quindi BMP.

Posso chiederti come mai odi questo stile di strutturazione?
Quale metodo prediligi?

Io ho sviluppato in questo modo in quanto mi è sembrato molto naturale.
A lavoro finito mi sono ovviamente venuti i dubbi,che come ho detto ,riguardano soprattutto la performance e l'affidabilità.Il fatto che sia un pivelletto novizio con queste tecnologie poi mi fa far dei viaggi mentali...altro che film di star wars!

[nuovoUtente86]

Originariamente inviato da javacomelava

E' proprio cosi'. Da quello che hai detto confermi i miei dubbi. In questo modo ho pochi service EJB (centralizzando il codice),ma ogni service è bello corposo a livello di codice.La mia principale paura è quella di avere problemi di performance e affidabilità del sistema nel caso in cui molti client si connettessero all'applicazione.

Per quanto riguarda lo strato di persistenza ho deciso di gestirla da me con le mie manine,quindi BMP.

Posso chiederti come mai odi questo stile di strutturazione?
Quale metodo prediligi?

Io ho sviluppato in questo modo in quanto mi è sembrato molto naturale.
A lavoro finito mi sono ovviamente venuti i dubbi,che come ho detto ,riguardano soprattutto la performance e l'affidabilità.Il fatto che sia un pivelletto novizio con queste tecnologie poi mi fa far dei viaggi mentali...altro che film di star wars!

Il pattern facàde nasce come estensione del proxy, quindi l' intento è quello di esporre servizi celandone l' implementazione (le stesse classi DAO sono dei proxy, nascondendo di fatto i meccanismi di storage) mettendo in comunicazione tra loro oggetti affiatati. Spesso in letteratura è portato l' esempio di un client di posta con i vari moduli smtp, pop, correttore ortografico, ecc. In tale contesto l' utilizzo di un facàde trova una giustificazione, ma viceversa spessissimo si abusa di tale pattern accorpando anche entità logicamente scorrelate.
Quanto alla gestione programmatica, non la vedo affatto utile potendo sfruttare gli entity bean (quindi il meccanismo ORM) messi a disposizione dalla specifica 3 grazie alle api jpa.
La cosa più lineare è quella di mappare il dominio attraverso gli entity e spostare la logica (quindi ri-mappando il dominio nel livello applicativo)nei session, indipendentemente dal fatto che poi si opti per l' utilizzo dei session facàde o meno.