EJB3 Business Logic Patterns & amp; pratiche

Question

Sto sviluppando un'applicazione di elaborazione finanziaria multilivello in Java utilizzando EJB3 (Hibernate + Glassfish per l'app e il livello dei servizi Web, Lift on Glassfish per l'interfaccia utente Web) e sto affrontando la questione di dove mettere la mia logica di business.

Quando è iniziato questo progetto, la nostra prima idea era quella di mettere la maggior parte della nostra logica aziendale nei bean di sessione senza stato. Con il passare del tempo, tuttavia, abbiamo riscontrato che l'iniezione di dipendenza fornita dal framework EJB è troppo limitante, quindi molta della nostra logica aziendale è finita nei POJO che sono assemblati da Guice nel metodo @PostConstruct dei bean di sessione senza stato . Questo progresso ha portato alla frammentazione della nostra logica di business tra i bean di sessione e i POJO, e sto cercando di capire un approccio per correggere questo.

Inizialmente, abbiamo cercato di far sì che il nostro livello Web utilizzasse le interfacce remote dei bean di sessione per eseguire alcune funzioni accessibili sia dall'interfaccia utente sia dal livello del servizio Web, fornito dai bean di sessione stateless con annotazioni @ WebService. Questo si è rivelato un incubo dal punto di vista della persistenza e delle prestazioni, perché il nostro grafico delle entità può diventare piuttosto grande e ricollegare il grafico dell'entità distaccata al contesto di persistenza si è rivelato altamente soggetto a errori, quindi la nostra soluzione era iniziare semplicemente passando l'oggetto identificatori intorno e cercare le entità dal database ovunque fossero necessarie.

La mia domanda di base è questa: quali principi e linee guida puoi suggerire per decidere se la logica aziendale debba andare in un bean di sessione o in un POJO? Quando ha senso passare i bean di entità in giro, dato un grafico a oggetti complessi?

Answer 1

Ho lottato con questo mentre costruivo una webapp usando JPA, EJB3 e Wicket. Dato che colpire il mio database con ripetute query era più scalabile che contenere molte entità di grandi dimensioni in memoria, ho deciso di passare solo attraverso i loro ID e mai l'entità stessa.

Wicket e il suo concetto di modelli avevano molto a che fare con questa decisione. Il modello LoadableDetachableModel pulisce le entità quando non sono in uso, mantenendo comunque l'ID. È implementato un metodo load () che sa come ottenere l'entità quando è nuovamente necessario, nel mio caso chiamando un bean di sessione senza stato; e un metodo persist () chiama il bean stateless per mantenere le modifiche. Questa classe di modello è ciò che in realtà passo in giro. Wicket gestisce solo la logica relativa alla visualizzazione e alla convalida dell'input e ho solo bisogno di iniettare l'ejb nelle classi del modello. Forse potresti creare qualcosa di simile nella tua app (non ho idea di cosa abbia da offrire l'ascensore ...).

Questo ha funzionato bene per me, ma non ho una logica aziendale particolarmente complessa e posso isolare eventuali cambiamenti che devono essere persistiti in piccole unità di logica e singole pagine.

Answer 2

Ogni volta che hai bisogno di molti "sistemi" i servizi (iniezioni, ecc.) utilizzano bean stateless. Altrimenti - POJO. I POJO sono molto più flessibili.

Tuttavia, i metodi semplici (accessor?) (ad es. in webservices e bean) possono fare solo un semplice lavoro e restituire i risultati.