OpenSessionInView vs PersistentContext (Extended)

Question

Sto lavorando su un'architettura Hibernate/JPA/Spring/Zk e moltiplico le domande in questi giorni perché devo imparare un sacco di framework.

Ho una domanda che mi lascia perplesso per diversi giorni.

Ho sentito parlare del "pattern" OpenSessionInView per mantenere attiva una transazione Hibernate per effettuare il caricamento lazy. Molti dicono anche che il modello non è molto pulito.

E, dall'altro, si dice che PersistentContext esteso non è thread-safe, e quindi non è adatto per mantenere in vita l'entityManager.

Quindi, qual è la vera soluzione a questi problemi? Suppongo che questi problemi nascano dall'introduzione di ajax che consente maggiori possibilità, specialmente con il caricamento lazy, per caricare alcune raccolte pesanti quando necessario.

Per il momento, ho provato @PersistenceContext in modalità estesa. Funziona ... Ho dovuto impostarlo per i miei test JUnit, e funziona anche nella mia applicazione web con caricamento lazy senza più configurazioni.

È che l'evoluzione del framework (Spring, JPA 2.0) significa che ora è più semplice e più "pulito" funzionare con PersistentContext?

Se questo non è il caso, dovremmo usare OpenSessionInViewFilter da Spring e sostituire PersistentContext in modalità transazionale?

Grazie.

Answer 1

Ho sentito. Ho implementato entrambi i modelli in diverse applicazioni dal 2008. Ora, abbandono del tutto gli schemi statistici. Quando si introduce lo stato sul client, si pongono problemi di scalabilità e gestione dello stato: si fondono in client, si salva nella sessione utente, cosa succede quando si cammina attraverso una procedura guidata e l'oggetto deve essere transitorio prima del salvataggio? Come sincronizzeresti lo stato di client e server? Cosa succede quando cambia db - si rompe il client?

Osservare la tendenza delle tecnologie esistenti, incluso Spring MVC: il modello prevede la costruzione di due progetti: 1) restful webservices 2) interfacce utente. Lo stato è condiviso attraverso un modello di dominio immutabile. Certo si potrebbe finire per mantenere un insieme di dtos, ma sono prevedibili, economici e scalabili all'infinito.

La mia raccomandazione? Evitare di inviare oggetti con proxy sul cavo e gestire dtos sul client o condividere un modello di dominio con il client se si desidera riutilizzare le convalide serveride. Le raccolte pigre possono essere caricate tramite chiamate api a grana fine tramite Ajax. In questo modo, tu dai il controllo completo al cliente.

Ecco come il social web si è ridimensionato negli ultimi cinque anni.