ibernare, essere pigro o non essere pigro?

Question

Ho entity A, che ha una relazione molti-a-molti con entity B.

Quindi la disposizione della tabella è: A, AB(mapping table), B

per ottenere un oggetto di un'entità A: io chiamo A.getById() che fa getHibernateTemplate().get(A.class, id) utilizzando la primavera e Sospensione.

Il problema è, codice a volte conseguente sarà solo bisogno di un codice a volte conseguente continuerà per accedere al associata B del, quindi vorremmo utilizzare caricamento pigro in alcuni casi e desiderosi in alcuni altri casi. ma il problema è che tutti gli accessi al database sono forniti attraverso lo stesso singolo ADao.java, quindi esiste un solo metodo getById().

Devo creare due versioni del metodo getById()?

Ma per i casi più complessi, se A è anche collegato a C attraverso molti-a-molti, allora ci potrebbe essere varianti di lazy-loading-C e ansioso-carico-C, quindi la richiesta getById() varianti rapidamente cresce esponenzialmente

qual è la vostra opinione su questa scelta?

Grazie

Answer 1

Per considerazioni di carattere generale, dare un'occhiata ai documenti di Hibernate 3.6 su fetching strategies. La strategia di recupero predefinita è definita nella mappatura delle annotazioni o in un file hbm.xml. Esistono tre modi per passare dinamicamente da una strategia di caricamento lazy predefinita a una strategia di caricamento impaziente. I primi due richiedono implementazioni separate di metodi DAO per pigrizia caricamento e sull'uso ansioso-loading casi:

1. Criteria.setFetchMode() in una query Criteri Sospensione
2. FETCH parola chiave in una query HQL
3. Da Sospensione 3.5 (non proprio certo ora, forse 3.6) c'è la terza possibilità di usare fetch profiles per passare dinamicamente da lazy-load a caricamento-caricamento.

Un profilo di recupero è abilitato/disabilitato su un ambito di sessione. Pertanto, a condizione che il profilo fetch desiderato sia impostato nella sessione corrente, è possibile utilizzare lo stesso metodo DAO per un caricamento lazy e per un caso d'uso con caricamento impaziente.

La cosa importante da tenere presente è che si possibile passare solo da una strategia lazy-carico definito nelle annotazioni o in un file hbm.xml ad una strategia ansioso-carico e non viceversa. Questa restrizione è indipendente dal metodo utilizzato per cambiare la strategia di recupero.

Answer 2

Bene, hai descritto correttamente il problema. È solo un compromesso tra semplicità (un solo metodo) e prestazioni (due metodi, ognuno che restituisce esattamente ciò che è necessario). Se il tempo di risposta è corretto, basta usare il metodo singolo e caricare pigro i Bs, quindi non toccare nulla. Se il tempo di risposta è troppo lungo e hai misurato il carico di caricamento che lo renderebbe corretto, quindi introduci un nuovo metodo.

Mantieni le cose semplici e ottimizza solo se necessario. Le associazioni di caricamento lento sono veloci, perché eseguono semplicemente una query su una chiave esterna, che dovrebbe essere indicizzata nel database.

Inoltre, non è abbastanza raro caricare due o più associazioni: è comune mostrare tutti i prodotti di una categoria in una pagina, ma è raro mostrare tutti i prodotti di tutti i prodotti di una categoria.