ORM: proxy di runtime vs strumentazione bytecode

5

Quali sono i vantaggi dell'utilizzo di proxy di runtime con un provider ORM come Hibernate o EclipseLink rispetto alla strumentazione / miglioramento del codice?

So che la strumentazione bytecode aiuta a ottimizzare il controllo sporco. Poiché è in grado di intercettare le modifiche, il provider ORM non ha bisogno di attraversare tutti gli oggetti nel contesto di persistenza e confrontare i valori correnti con lo snapshot eseguito quando gli oggetti sono stati caricati (evitando così anche il consumo di memoria aggiuntivo, presumo).

Inoltre, so che può essere d'aiuto in situazioni in cui devono essere eseguite ulteriori query perché il provider ORM non sa se è necessario creare un proxy o quale sia il valore della chiave primaria nel proxy, come in < a href="https://stackoverflow.com/questions/1444227/making-a-onetoone-relation-lazy"> lazy one-to-one associazioni, rendendo così le associazioni effettivamente ansiose in alcune situazioni.

Alcune altre insidie del proxy sono state descritte in questo blog , come accesso diretto al campo (in equals e hashCode metodi) e utilizzo di instanceof operatore.

Mi sembra che la strumentazione bytecode sia un'alternativa migliore. Ha qualche insidia propria rispetto all'approccio dei proxy di runtime? C'è qualche regola empirica da seguire quando si sceglie l'uno invece dell'altro?

    
posta Dragan Bozanovic 14.07.2015 - 13:58
fonte

1 risposta

2

Sia Hibernate che EclipseLink utilizzano il modello di progettazione Proxy per implementare il caricamento pigro / ansioso delle relazioni di entità. I proxy sono intrecciati in bytecode Java in fase di compilazione (staticamente) o in fase di esecuzione (in modo dinamico), in pratica migliorando i POJO delle entità. Altre caratteristiche, come il controllo sporco, sono anche inserite nel bytecode.

Questa è un'applicazione di Aspect Oriented Programming (AOP). Si applicano tutte le stesse insidie (ad esempio classi inaspettate in fase di esecuzione) e vantaggi (ad esempio, codice sorgente più pulito, iniezione del codice runtime).

Quindi la domanda è, quali sono le alternative? È possibile disabilitare la tessitura e implementare le stesse funzionalità (caricamento lento, controllo sporco, ecc.) Nel proprio codice, senza sorprese di runtime, ma con un maggiore sforzo di sviluppo.

Come regola generale, usa le annotazioni, evita il controllo della classe di entità di runtime e affidati alla tessitura del codice Hibernate o Eclipselink per consegnare ciò che desideri. Nota che hai sempre la possibilità di implementare i tuoi proxy personali, ecc. Se la complessità lo richiede.

    
risposta data 22.07.2015 - 02:03
fonte

Leggi altre domande sui tag