Quando puoi/dovresti andare fino in fondo con l'approccio ORM?

Question

Mi sembra che l'introduzione di uno strumento ORM dovrebbe rendere la tua architettura più pulita, ma per motivi di efficienza mi sono ritrovato a bypassarlo e a ripetere occasionalmente un set di risultati JDBC.Ciò porta a un groviglio scoordinato di artefatti invece che a un'architettura più pulita.

È perché sto applicando lo strumento in un contesto non valido o la questione è più profonda?

Quando puoi/dovresti andare fino in fondo con l'approccio ORM?

Qualsiasi intuizione sarebbe molto apprezzata.

---

Un po' di background:

Nel mio ambiente ho circa 50 computer client e 1 SQL Server ragionevolmente potente.

Ho un'applicazione desktop in cui tutti i 50 client accedono ai dati in ogni momento.

Il modello di dati del progetto ha subito una serie di riorganizzazioni per vari motivi, tra cui chiarezza, efficienza, ecc.

La cronologia del mio modello di dati

1. JDBC chiama direttamente
2. DAO + POJO senza relazioni tra Pojo (sostanzialmente avvolgendo il JDBC).
3. Aggiunte relazioni tra POJO che implementano il Lazy Loading, nascondendo però solo le chiamate inter-DAO
4. Sono saltato sul carro di Hibernate dopo aver visto quanto "semplice" rendeva l'accesso ai dati (rendeva banali le relazioni tra POJO) e perché poteva ridurre il numero di viaggi di andata e ritorno al database quando si lavora con molte entità correlate.
5. Dato che si trattava di un'applicazione desktop, mantenere le sessioni aperte a lungo termine era un incubo, quindi finì per causare molti problemi
6. Sono tornato a un approccio DAO/Hibernate parziale che mi consente di effettuare chiamate JDBC dirette dietro il sipario DAO mentre allo stesso tempo utilizzo Hibernate.

Answer 1

L'ibernazione ha più senso quando l'applicazione funziona grafici degli oggetti, che sono persistenti nell'RDBMS.Invece, se la logica dell'applicazione funziona su una matrice di dati 2D, recuperarli tramite JDBC diretto funziona meglio.Sebbene Hibernate sia scritto su JDBC, ha funzionalità che potrebbero non essere banali da implementare in JDBC.Per esempio:

1. Supponiamo che l'utente visualizzi una riga nell'interfaccia utente e modifichi alcuni valori e desideri avviare una query di aggiornamento solo per quelle colonne che sono effettivamente cambiate.
2. Per evitare di entrare in situazioni di stallo è necessario mantenere un ordine globale per gli SQL in una transazione.Ottenere questo JDBC corretto potrebbe non essere facile
3. Impostazione semplice del blocco ottimistico.Quando usi JDBC, devi ricordarti di averlo in ogni query di aggiornamento.
4. Anche gli aggiornamenti batch, la materializzazione pigra delle raccolte ecc. potrebbero non essere banali da implementare in JDBC.

(Dico "Potrebbe essere non banale", perché ovviamente si può fare - e potresti essere un super hacker :)

Hibernate ti consente anche di avviare le tue query SQL, nel caso sia necessario.

Spero che questo ti aiuti a decidere.

PS:Mantenere la sessione aperta su un client desktop remoto e incorrere in problemi non è in realtà un problema di Hibernate: ti imbatteresti nello stesso problema se mantieni aperta a lungo la connessione al DB.