Utilizzo del framework Hibernate Criteria per query complesse rispetto alla sola creazione di viste in DB

Question

Utilizzo del framework Hibernate Criteria per query complesse rispetto alla sola creazione di viste in DB

#1 da (1 voti)
#2 da (1 voti)

1

Mi piace usare Hibernate per le normali operazioni% CRUD .

Tuttavia, sto cercando di capire perché qualcuno dovrebbe ricorrere al suo Criteria framework per assemblare criteri di recordset complessi anziché creare semplicemente una vista a livello di database.

es. Ecco un frammento parafrasato con cui sto lavorando:

Criteria tableCriteria = session
    .createCriteria(SomeEntity.class)
    .add(Restrictions.eq("someID", someID))
    .add(Restrictions.gtProperty("scoreOne", "scoreTwo"))
    .add(Restrictions.gt("scoreThree", scoreThreeMin))
    .add(Restrictions.or(Restrictions.eq("inactive", Boolean.FALSE), Restrictions.isNull("inactive"))).addOrder(Order.asc("ordCol"))

Da una prospettiva a occhio nudo, è possibile, ma lascia che sia leggibile il discernimento di ciò che stabilisce questa definizione di filtro piuttosto che semplicemente creare una vista DB in cui queste restrizioni potrebbero essere espresse sotto forma di clausole WHERE più semplici.

Mi manca qualcosa? C'è un vantaggio nell'usare le viste Criteria vs. DB di cui non sono a conoscenza? L'uso delle viste sembra molto più pulito. C'è un rialzo delle prestazioni rispetto ai criteri?

java database hibernate

posta amphibient 06.02.2014 - 22:38

fonte

2 risposte

Leggi altre domande sui tag java database hibernate

Quale processo di sviluppo incoraggia le versioni frequenti (rolling code a un sito attivo), nonché l'individualità dello sviluppatore Auto Transaction Failsafe, API di terze parti, file di pianificazione Coldfusion

score 1 · Answer 1

Il vantaggio principale dell'utilizzo del framework Criteria è la creazione di query programmatiche e, come suggerisce Aaronaught, è molto più semplice con Criteria eseguire una query arbitrariamente complessa su molti RDBMS diversi da quella con una vista denominata di cui avrebbe bisogno da creare e gestire separatamente.

A seconda della situazione (e del tuo esempio), una vista potrebbe essere più manutenibile e facilmente ottimizzata. HQL sarebbe sicuramente più facile da leggere.

score 1 · Answer 2

Dal punto di vista del database, è più probabile che tu possa scrivere una vista migliore. Potresti essere in grado di sovrapporre le viste insieme, dove alcune viste contengono parti distinte e riutilizzabili della logica aziendale. Quando ci si avvicina a questo modo modulare si riduce notevolmente la probabilità di avere un numero eccessivo di visualizzazioni. E questo dovrebbe semplificare le cose nelle "migliaia" di applicazioni Java che le utilizzano, riducendo i costi di sviluppo, manutenzione e prestazioni sul lato Java.

Potrebbe funzionare bene in alcuni ambienti in cui si ha a che fare con un singolo DBMS. Questo pone anche le basi per l'utilizzo al di fuori del gruppo di sviluppo java. Potrebbero esserci applicazioni che desiderano utilizzare altri metodi di accesso, ora o in futuro.

Naturalmente alcuni DBMS potrebbero non ottimizzare l'approccio a viste stratificate come pure il mio. YMMV.