Java EE 6 - Il pattern Persistent Domain Objects: eventuali successi?

Question

Ho un'applicazione moderatamente complessa che utilizza POJO e ora viene migrata a EJB3.1 in modo che possa essere distribuita online, accessibile tramite i servizi REST e beneficiare dell'ambiente contenitore (la persistenza è la più importante, ma le transazioni sarebbero utili pure).

Sono stato lontano da Java EE dai giorni J2EE, e sto lottando per capire la "perdita" dei bean di entità. Mi ci è voluto un po 'per capire che le Entità in EJB3.1 non sono in realtà Fagioli nel vecchio senso ... :) Ho letto un numero di libri EJB3 incluso il "manuale" O'Reilly Enterprise JavaBeans 3.1, che spiegano tutti i concetti e i componenti di EJB3 ma non le opzioni del modello di implementazione.

Nella mia ricerca e ricerca alla ricerca di modelli Java EE 6 sono piuttosto preso dall'approccio di Adam Bien - in particolare il pattern "Persistent Domain Objects" (PDO) (nel suo libro ma riassunto anche qui: http://download.java.net/general/podcasts/real_world_java_ee_patterns.pdf), che appare offrire la minima complessità e sinergia con la mia attuale app POJO. DOP si allinea strettamente con le tradizionali filosofie orientate agli oggetti e l'approccio, e mi piace davvero.

Anziché rispecchiare un dibattito su DOP, sono interessato a conoscere le persone che lo hanno implementato e ciò che ha funzionato rispetto a dove si sono verificate delle difficoltà. In particolare mi piacerebbe scoprire come hai effettuato chiamate dalle entità JPA ad altri servizi nel contenitore (come le chiamate ai bean di sessione stateless, ecc.).

Mi piacerebbe anche sapere se ci sono alternative al pattern PDO che mi consentono di mantenere la struttura dell'applicazione (usando il polimorfismo, ecc.) Senza dover creare un bean di sessione e un'entità JPA per ogni classe nel mio modello. (Non voglio farlo in parte a causa del massiccio esercizio richiesto per refactoring di tutti i test di unità e di integrazione, e in parte perché - per quanto posso vedere - finirò per provare a replicare la mia relazione di oggetti 1 in molti ecc. anche i miei fagioli di sessione sembrano pazzi).

Qualcuno ha qualche esperienza da condividere - o se si desidera sottolineare che sono un idiota e ho perso qualcosa di fondamentale in Java EE 6, che sarebbe "benvenuto" troppo :)

TIA

Answer 1

No, risponde così forse io sono l'unico a farlo;) per chiunque altro alla ricerca di puntatori, ho trovato:

• vostro modello a oggetti necessita di una modifica importante. Non è possibile utilizzare Maps o gli elenchi di interfacce come in un'applicazione non JPA, poiché JPA non può gestire interfacce "handle" , è necessario mantenere (astratte) le classi. Hibernate ha un'annotazione @Any e @ManyToAny, ma l'overhead (prestazioni, funzionalità e codifica) è significativo (IMHO). Se puoi implementare un'orribile gerarchia di classi astratte allora dovresti. YUK!

• Se si dispone di un modello di oggetto vagamente complesso (più di sei relazioni tra oggetti), si otterrà un LOTTO di comandi JOIN nel codice SQL generato dal motore JPA. Ho letto da qualche parte che> 6 JOINS mette un carico elevato sul database (sono solo una regola empirica, ne sono sicuro). MySQL ha un limite rigido di 61 join. Sembra pazzamente alto, sicuramente non l'avresti mai colpito ?! Se hai una gerarchia di oggetti astratti e alcune relazioni tra gli oggetti, questa viene presto aggiunta!

non ho trovato un modo per aggirare il primo "problema".Sembra sbagliato inserire molte classi base astratte invece di interfacce, ma per quanto posso vedere è inevitabile. Per favore dimmi se no!

Il secondo problema può essere gestito utilizzando lazy-fetch sulle relazioni tra oggetti o utilizzando il modello di gateway di Adam e le sessioni di persistenza estese (anziché i bean di sessione stateless che caricano e salvano il modello in ogni chiamata). Sto andando con quest'ultimo fino ad ora - ma non sono arrivato al punto in cui posso ancora caricare il test sulla memoria e sull'uso del database. Vedremo!