Quale Java ORM preferisci e perché? [chiuso]

È una domanda piuttosto aperta. Inizierò un nuovo progetto e cercherò diversi ORM da integrare con l'accesso al database.

Hai dei preferiti? C'è qualcuno di cui consiglieresti di stare alla larga?

Ho smesso di usare gli ORM.

Il motivo non è un grande difetto nel concetto. Hibernate funziona bene. Invece, ho scoperto che le query hanno un sovraccarico basso e posso adattare molta logica complessa a query SQL di grandi dimensioni e spostare gran parte della mia elaborazione nel database.

Quindi considera solo l'uso del pacchetto JDBC.

Nessuno, perché avere un ORM toglie troppo controllo con piccoli benefici. I risparmi di tempo guadagnati vengono facilmente eliminati quando è necessario eseguire il debug delle anomalie derivanti dall'uso dell'ORM. Inoltre, gli ORM scoraggiano gli sviluppatori dall'apprendimento di SQL e dal modo in cui i database relazionali funzionano e lo utilizzano a loro vantaggio.

Molti ORM sono fantastici, devi sapere perché vuoi aggiungere astrazione su JDBC. Posso consigliarti http://www.jooq.org (dichiarazione di non responsabilità: sono il creatore di jOOQ, quindi questa risposta è parziale). jOOQ abbraccia il seguente paradigma:

• SQL è una buona cosa. Molte cose possono essere espresse abbastanza bene in SQL. Non è necessaria un'astrazione completa di SQL.
• Il modello di dati relazionali è una buona cosa. Ha dimostrato il miglior modello di dati negli ultimi 40 anni. Non sono necessari database XML o modelli di dati realmente orientati agli oggetti. Invece, la tua azienda esegue diverse istanze di Oracle, MySQL, MSSQL, DB2 o qualsiasi altro RDBMS.
• SQL ha una struttura e una sintassi. Non dovrebbe essere espresso usando la concatenazione di stringhe "di basso livello" in JDBC - o la concatenazione di stringhe "di alto livello" in HQL - entrambi inclini a contenere errori di sintassi.
• L'associazione variabile tende ad essere molto complessa quando si affrontano query importanti. È qualcosa che dovrebbe essere astratto.
• I POJO sono ottimi quando si scrive codice Java manipolando i dati del database.
• I POJO sono un dolore da scrivere e mantenere manualmente. La generazione del codice è la strada da percorrere. Avrai query sicure per la compilazione, incluso datatype-safety.
• Il database viene prima di tutto. Mentre l'applicazione nella parte superiore del database può cambiare nel tempo, probabilmente il database stesso durerà più a lungo.
• Sì, nel tuo database legacy sono presenti procedure memorizzate e tipi definiti dall'utente (UDT). Il tuo strumento di database dovrebbe supportarlo.

Ci sono molti altri buoni ORM. Soprattutto Hibernate o iBATIS hanno una grande comunità. Ma se stai cercando uno intuitivo e semplice, ti dirò di provare jOOQ. Ti piacerà! :-)

Dai un'occhiata a questo esempio SQL:

  // Select authors with books that are sold out
  SELECT * 
    FROM T_AUTHOR a
   WHERE EXISTS (SELECT 1
                   FROM T_BOOK
                  WHERE T_BOOK.STATUS = 'SOLD OUT'
                    AND T_BOOK.AUTHOR_ID = a.ID);

E come può essere espresso in jOOQ:

  // Alias the author table
  TAuthor a = T_AUTHOR.as("a");

  // Use the aliased table in the select statement
  create.selectFrom(a)
        .whereExists(create.selectOne()
                           .from(T_BOOK)
                           .where(T_BOOK.STATUS.equal(TBookStatus.SOLD_OUT)
                           .and(T_BOOK.AUTHOR_ID.equal(a.ID))))));

Ibernazione, perché è fondamentalmente lo standard defacto in Java ed è stata una delle forze trainanti nella creazione dell'APP. Ha un eccellente supporto in primavera e quasi tutti i framework Java lo supportano. Infine, GORM è un vero e proprio wrapper attorno a sé che ricerca dinamici e così via usando Groovy.

È stato anche portato su .NET (NHibernate), quindi puoi usarlo anche lì.

Iberna, perché:

• è stabile - essendo in circolazione per così tanti anni, non ha problemi importanti
• detta gli standard nel campo ORM
• implementa lo standard (JPA), oltre a dettarlo.
• ha tonnellate di informazioni al riguardo su Internet. Esistono molti tutorial, soluzioni di problemi comuni, ecc
• è potente: puoi tradurre un modello a oggetti molto complesso in un modello relazionale.
• ha il supporto per qualsiasi RDBMS principale e medio
• è facile lavorare con te, una volta che lo impari bene

Alcuni punti sul perché (e quando) utilizzare ORM:

• lavori con oggetti nel tuo sistema (se il tuo sistema è stato progettato bene). Anche se usi JDBC, finirai per creare un livello di traduzione, in modo da trasferire i tuoi dati sui tuoi oggetti. Ma le mie scommesse sono che l'ibernazione è migliore nella traduzione rispetto a qualsiasi soluzione su misura.
• non ti priva del controllo. Puoi controllare le cose con dettagli molto piccoli e se l'API non ha alcune funzionalità remote, esegui una query nativa e ce l'hai.
• qualsiasi sistema di medie o grandi dimensioni non può permettersi di avere una tonnellata di query (che si tratti di un punto o sparse), se mira a essere mantenibile
• se le prestazioni non sono critiche. Hibernate aggiunge un sovraccarico prestazionale, che in alcuni casi non può essere ignorato.

Consiglierei di usare MyBatis . È un sottile strato sopra JDBC, è molto facile mappare oggetti su tabelle e usare ancora il semplice SQL, tutto è sotto il tuo controllo.

Ho avuto un'ottima esperienza con Avaje Ebean mentre stavo scrivendo un'applicazione JavaSE di medie dimensioni.

Utilizza le annotazioni JPA standard per definire le entità, ma espone un'API molto più semplice (nessun EntityManager o una qualsiasi delle cazzate di entità collegate / staccate). Inoltre, consente di utilizzare facilmente query SQL o chiamate JDBC di eventi semplici quando necessario.

Ha anche un'API molto fluida e sicura per le query. Puoi scrivere cose come:

List<Person> boys = Ebean.find(Person.class)
                                  .where()
                                       .eq("gender", "M")
                                       .le("age", 18)
                                  .orderBy("firstName")
                                  .findList();

SimpleORM , perché è semplice e senza magia. Definisce tutte le strutture di metadati nel codice Java ed è molto flessibile.

SimpleORM fornisce funzionalità simili a Hibernate mappando i dati in un database relazionale su oggetti Java in memoria. Le query possono essere specificate in termini di oggetti Java, l'identità dell'oggetto è allineata con le chiavi del database, le relazioni tra gli oggetti vengono mantenute e gli oggetti modificati vengono automaticamente scaricati nel database con blocchi ottimistici.

Ma a differenza di Hibernate, SimpleORM utilizza una struttura e un'architettura di oggetti molto semplici che evitano la necessità di analisi complesse, elaborazione di codici byte ecc. SimpleORM è piccolo e trasparente, confezionato in due vasetti di appena 79K e 52K di dimensioni, con un solo piccolo e opzionale dipendenza (Slf4j). (Hibernate è oltre 2400 K più circa 2000 K di barattoli dipendenti.) Ciò rende SimpleORM di facile comprensione e riduce notevolmente il rischio tecnico.

Eclipse Link , per molte ragioni, ma in particolare mi sento come se avesse meno gonfiore rispetto ad altre soluzioni di flusso principali (almeno meno gonfiore in faccia).

Oh ed Eclipse Link è stato scelto come implementazione di riferimento per JPA 2.0

Mentre condivido le preoccupazioni riguardanti le sostituzioni Java per le query SQL in formato libero, penso davvero che le persone che criticano ORM lo stiano facendo a causa di una progettazione delle applicazioni generalmente scadente.

True OOD è guidato da classi e relazioni e ORM offre una mappatura coerente di diversi tipi e oggetti di relazione. Se usi uno strumento ORM e finisci per codificare espressioni di query in qualsiasi linguaggio di query supportato dal framework ORM (incluso, ma non limitato a alberi di espressioni Java, metodi di query, OQL ecc.), Stai sicuramente facendo qualcosa di sbagliato, cioè il tuo modello di classe molto probabilmente non supporta le tue esigenze nel modo in cui dovrebbe. Un design pulito dell'applicazione non ha davvero bisogno di query a livello di applicazione. Ho eseguito il refactoring di molti progetti che le persone hanno iniziato a utilizzare un framework ORM nello stesso modo in cui sono stati utilizzati per incorporare costanti di stringhe SQL nel loro codice e alla fine tutti sono rimasti sorpresi di quanto sia semplice e gestibile l'intera applicazione una volta abbinata il tuo modello di classe con il modello di utilizzo. Certo, per cose come la funzionalità di ricerca ecc. Hai bisogno di un linguaggio di query, ma anche in questo caso le query sono così limitate che la creazione di una VISTA e la mappatura anche complesse che a una classe persistente di sola lettura è molto più facile da mantenere e guardare rispetto alla creazione di espressioni in un linguaggio di query nel codice dell'applicazione. L'approccio VIEW sfrutta anche le capacità del database e, attraverso la materializzazione, può essere molto più efficiente dal punto di vista delle prestazioni rispetto a qualsiasi SQL scritto a mano nella tua sorgente Java. Quindi, non vedo alcun motivo per un'applicazione non banale NON utilizzare ORM. ma anche in questo caso le query sono così limitate che la creazione di una VISTA e la mappatura anche complesse che a una classe persistente di sola lettura è molto più semplice da mantenere e da guardare rispetto alla creazione di espressioni in un linguaggio di query nel codice dell'applicazione. L'approccio VIEW sfrutta anche le capacità del database e, attraverso la materializzazione, può essere molto più efficiente dal punto di vista delle prestazioni rispetto a qualsiasi SQL scritto a mano nella tua sorgente Java. Quindi, non vedo alcun motivo per un'applicazione non banale NON utilizzare ORM. ma anche in questo caso le query sono così limitate che la creazione di una VISTA e la mappatura anche complesse che a una classe persistente di sola lettura è molto più semplice da mantenere e da guardare rispetto alla creazione di espressioni in un linguaggio di query nel codice dell'applicazione. L'approccio VIEW sfrutta anche le capacità del database e, attraverso la materializzazione, può essere molto più efficiente dal punto di vista delle prestazioni rispetto a qualsiasi SQL scritto a mano nella tua sorgente Java. Quindi, non vedo alcun motivo per un'applicazione non banale NON utilizzare ORM.