Come funziona ORM sotto le coperte? Inoltre, qual è il modo migliore per avere oggetti persistenti in Java?

Question

Come funziona ORM? Gli oggetti sono serializzati in BLOB?

In Java, JDO è ancora la strada da percorrere per questo? Cos'altro è disponibile? Sembra che si sia parlato molto di EJB, serializzazione diretta degli oggetti e JDO.

Answer 1

Per rispondere alla tua prima domanda, ecco un estratto da Hibernate in Action , che dice che ci sono vari modi per implementare ORM:

  

Puro relazionale

     

L'intera applicazione, incluso il   interfaccia utente, è progettata intorno al   modello relazionale e basato su SQL   operazioni relazionali. Questo approccio,   nonostante le sue carenze in generale   sistemi, può essere un'ottima soluzione   per applicazioni semplici dove un basso   il livello di riutilizzo del codice è tollerabile.   Direct SQL può essere ottimizzato in ogni   aspetto, ma gli svantaggi, come ad esempio   mancanza di portabilità e   manutenibilità, sono significativi,   soprattutto a lungo termine.   Applicazioni in questa categoria spesso   fare un uso pesante delle procedure memorizzate,   spostando parte del lavoro fuori dal   livello aziendale e nel database.

     

Mappatura oggetti luce

     

Le entità sono rappresentate come classi   che sono mappati manualmente su   tabelle relazionali. SQL / JDBC con codifica manuale   è nascosto dalla logica aziendale   utilizzando modelli di design noti.   Questo approccio è estremamente diffuso   ed è efficace per le applicazioni   con un numero limitato di entità, o   applicazioni con generico,   modelli di dati basati su metadati. Immagazzinato   le procedure potrebbero avere un posto in questo   tipo di applicazione.

     

Mappatura oggetti media

     

L'applicazione è progettata attorno a un   modello a oggetti. SQL viene generato in   tempo di costruzione usando una generazione di codice   strumento o in fase di esecuzione per codice framework.   Le associazioni tra oggetti sono   supportato dalla persistenza   meccanismo e potrebbero essere richieste   specificato utilizzando un oggetto orientato   linguaggio delle espressioni. Gli oggetti sono   memorizzato nella cache dal livello di persistenza. UN   moltissimi prodotti ORM e fatti in casa   i livelli di persistenza supportano almeno   questo livello di funzionalità. Va bene   adatto per applicazioni di medie dimensioni   con alcune transazioni complesse,   in particolare quando la portabilità tra   diversi prodotti di database è   importante. Queste applicazioni di solito   non utilizzare le procedure memorizzate.

     

Mappatura completa degli oggetti

     

Supporta la mappatura completa degli oggetti   sofisticata modellazione di oggetti:   composizione, eredità,   polimorfismo e "persistenza di   raggiungibilità. ”Il livello di persistenza   implementa la persistenza trasparente;   le classi persistenti non ereditano alcuna   classe base speciale o devono   implementare un'interfaccia speciale.   Strategie di recupero efficienti (pigro   e desideroso di recuperare) e la memorizzazione nella cache   le strategie sono implementate   in modo trasparente all'applicazione. Questo   il livello di funzionalità difficilmente può essere   raggiunto da una persistenza nostrana   livello: è equivalente a mesi o   anni di tempo di sviluppo. Un numero   di ORM Java commerciale e open source   gli strumenti hanno raggiunto questo livello di   qualità. Questo livello soddisfa il   definizione di ORM che stiamo utilizzando in questo   libro. Diamo un'occhiata ai problemi che abbiamo   aspettarsi di essere risolto da uno strumento che   ottiene la mappatura completa degli oggetti.

Answer 2

ORM = Mappatura relazionale oggetto, gli attributi degli oggetti sono mappati su colonne nel database realazionale. Quella mappatura è arbitraria, quindi potrebbe essere fatta ai BLOB, in pratica ciò che è più utile tende alle mappature naturali - Stringhe a Varchars, int a numeri interi ecc.

JPA è il luogo in cui cercare uno standard per ORM. L'APP sostituisce l'approccio CMP dell'EJB, ritenuto ingombrante. JPA consente di esprimere la mappatura come annotazioni Java e consente inoltre di specificare le mappature nei file di configutrazione, quando il supporto di più [database di quest'ultima può essere utile.

JPA ha un linguaggio di query in modo da poter costruire query sugli attributi degli oggetti.

JPA è supportato dai principali fornitori di App Server e anche da prodotti come Hibernate.

Ho trovato JPA molto carino con cui lavorare, più che con EJB CMP.

Raccomanderei di usare ancora le facciate dei bean di sessione EJB per la confusione e la sicurezza delle transazioni - l'approccio basato sulle annotazioni rende EJB 3 way più facile da usare rispetto a EJB 2, un overhead minimo di codifica.

Answer 3

JDO è in realtà anche ORM standard e fornisce una specifica più completa di JPA (1 + 2). JPQL è più focalizzato sui concetti RDBMS e quindi imita SQL. JDOQL segue la sintassi Java, quindi è più basato sugli oggetti. Dipende se la tua app viene mai considerata come andare via da RDBMS. In tal caso, JPA non è la strada da percorrere. Se è esclusivamente per RDBMS, JPA è sicuramente una considerazione.

La serializzazione degli oggetti in BLOB dipende dalla configurazione. Se lo desideri, puoi farlo per tipi di oggetti complessi, ma non saranno interrogabili. Se invece li persisti in un formato nativo, puoi anche interrogarli, portando ad app più efficienti.

--Andy (DataNucleus - Persistenza JDO e JPA)