Limitazione della complessità nei programmi JPA Java / Hibernate

Question

Limitazione della complessità nei programmi JPA Java / Hibernate

#1 da (1 voti)
#2 da (0 voti)
#3 da (0 voti)

1

Ho lavorato a una nuova applicazione da alcuni mesi. È il mio primo grande programma JPA, ed è ancora nelle prime fasi. Tuttavia, la complessità del mio albero di oggetti JPA sta diventando un problema in crescita.

Ad esempio, ho un albero degli oggetti degli utenti, che hanno società, divisioni, divisioni correlate, valute, valute locali, tassi di cambio valuta. Ai livelli più bassi, le cose non sono poi così male. Ad esempio, se ritiro le valute, le cose sono più facili da affrontare. Ma per elementi di alto livello, come un elenco di utenti, il mio albero degli oggetti è diventato orribile.

Ora, un piccolo bug è scivolato nella struttura ad albero JPA, il che significa che un'importante tabella di join viene sovrascritta da una delle mie entità. Spero di riuscire a trovare il bug, ma su cosa mi piacerebbe dare consigli su come evitare questa complessità in rapida espansione.

Grazie!

java orm hibernate jpa

posta wax_lyrical 08.01.2015 - 12:01

fonte

3 risposte

Leggi altre domande sui tag java orm hibernate jpa

RavenDb - Ottieni dati tramite un'API Web REST java aggiunge nuovi moduli a un'app esistente

score 1 · Answer 1

Il mio approccio è:

prefare relazioni unidirezionali (ad esempio quando carichi il ruolo, di solito non hai bisogno di tutti quelli con quel ruolo, e se ne hai bisogno per la gestione degli utenti, puoi farlo per quark)
prefare il caricamento lento, in modo da non manipolare i grafici enormi per sbaglio
se non hai bisogno dell'entità come risultato della query, restituisci oggetto non entità (tramite seleziona nuovo).
JPA non è sostitutivo di una buona analisi (non caricare solo oggetti e attraversarli, sapere di cosa hai bisogno e caricarlo)
prova a strutturare i tuoi oggetti in modo tale che non ci sia alcun oggetto da cui sia possibile arrivare da nessuna parte. invece di A < - B - > C usa A - > B < - C. Le informazioni per l'interrogazione sono disponibili, ma il grafico degli oggetti è suddiviso in parti, quindi la complessità è più vicina alla somma delle parti rispetto alla moltiplicazione delle parti.
crea una divisione intelligente tra codice in cui le entità sono attive e in cui le modifiche non entrano automaticamente nel database.

score 0 · Answer 2

Questa non è una risposta diretta, ma potresti considerare di ignorare del tutto le gerarchie di oggetti complesse e semplicemente di eseguire direttamente l'SQL nei casi più complessi.

Ho scritto un ORM semplice chiamato Norm perché non volevo sostenere tutto il sovraccarico di JPA. La teoria è che fai il minimo necessario per ottenere dati dentro e fuori dal database. Se il tuo ORM non può gestire ciò che devi fare, fallo in SQL.

score 0 · Answer 3

Potresti provare a utilizzare il caricamento lazy degli oggetti correlati (aziende, divisione, ecc.). Nel tuo livello aziendale, recupera gli oggetti correlati solo se ne hai bisogno. Di default saranno nulli e ti faranno risparmiare spazio. Se il caricamento lazy diventa troppo complesso (di solito a causa di ancora più annotazioni e configurazioni), puoi utilizzare riferimenti indiretti.

Quindi l'oggetto Utente dovrebbe essere:

public class User{
    Integer id;
    Integer companyId;
    Integer divisionId;

    //usual getters and setters

    //this is not a getter - notice the different in method name
    public Company fetchUserCompany(){
        //DAO call to retrieve Company by companyId defined in the User object
    }
}

In pratica questo approccio rende la gestione di gerarchie complesse molto semplice e puoi recuperare in sicurezza un ampio elenco di oggetti User senza preoccuparti dello spazio heap. Non è puramente "orientato agli oggetti". I bug sono più facili da trovare dal momento che il tuo UserDAO recupererà solo piccoli oggetti User. Nel caso in cui siano necessari gli oggetti correlati, la logica verrà delegata a CompanyDAO.

Nella mia esperienza ho visto che se la gerarchia non è molto profonda, il caricamento pigro è ok e facile da mantenere, tuttavia nel tuo caso potresti stare meglio con il secondo approccio.