springEREDITARIETA’ DELLE CLASSI ENTITY

Dal punto di vista tecnico, le classi di entità sono a tutti gli effetti delle classi Java che quindi rispettano le identiche regole di qualsiasi altra classe. Conseguentemente anche le classi di entità sono soggette ad ereditarietà; quindi, possono editare delle proprietà che provengono da superclassi. Guardiamo le classi Clienti Cards e Utente, queste tre classi hanno la medesima chiave primaria. Si potrebbe creare una classe magari astratta che implementi il CODFIDELITY  ed ereditarlo nelle classi sopra citate. Creiamo una nuova classe astratta AbstractEntityClienti. Le classi astratte definite come entity hanno bisogno di una specifica notazione in cima @MappedSuperclass. Il modificatore di accesso è protected e questo è normale perché le classi derivate dovranno accedere a questa proprietà. Una volta implementata questa classe astratta possiamo modificare le altre tre classi eliminando il campo privato codFidelity e i rispettivi getter e setter implementando la superclasse appena creata.

Classe astratta

LA NOTAZIONE @ATTRIBUTEOVERRIDE

Vediamo una situazione un po’ più complessa della precedente, introducendo una nuova tabella, la tabella Premi.

Premi

Notiamo immediatamente che il nome del campo, chiave primaria, nella tabella Premi è Fidelity, quindi è diverso solo il nome, ma la tipologia è la stessa. Vediamo ora cosa succede se creiamo la entity Premi e la facciamo derivare da AbstractEntityClienti. Se proviamo ad avviare l’applicazione otteniamo un errore di SQL Server in quanto non è stato rispettato il nome della colonna. Vediamo come si gestisce questa situazione. Andiamo nella tabella Premi e usiamo una nuova notazione, @AttributeOverride. La notazione @Basic è una alternativa di Hibernate rispetto a quanto visto sinora.

Table Premi

ARRICCHIRE LE CLASSI ENTITY CON LA NOTAZIONE @TRANSIENT

Sino a questo momento tutti i campi delle nostre entity sono coerenti con quelli delle rispettive tabelle. Ci sono situazioni in cui abbiamo bisogno di campi che non sono nella rispettiva tabella, allora per dire ad Hibernate che un particolare campo non è presente in tabella, quindi, non sarà soggetto a persistenza si usa la notazione @Transient. Creiamo un nuovo campo “nominativo” nella entity Clienti che andrà a sostituire il nome e il cognome. Nel getter di questo nuovo campo non soggetto a mappatura, andremo ad aggiungere il nome e il cognome separati da uno spazio. Ora possiamo modificare la vista clienti.jsp utilizzando il nominativo.

Transient

MAPPARE GLI ENUMERATORI

L’enumerazione che prenderemo in considerazione è il campo “stato” della tabella CLIENTI. Può assumere due valori, 1 stato attivo, 0 sospeso quindi non può ricevere punti fidelity. Creiamo un nuovo enumeratore nel nostro progetto Java chiamato Stato, e cambiamo il campo privato Stato della entity Clienti con il nuovo enumeratore.

Ordinal significa che l’enumerazione partirà da zero e andrà in ordine crescente. Non resta altro che modificare le viste inscliente e clienti.

Stato
Clienti

MAPPARE I LOB (LARGE OBJECT)

Si hanno questa tipologia di tipi quando ad esempio dobbiamo inserire nel database delle immagini.

LOB

C’è la possibilità all’interno di un database relazionare salvare ad esempio i byte di un’immagine o di qualsiasi altro tipo di file. Il FetchType che utilizziamo con un LOB è il LAZY, questo è molto importante perché essendo campi di natura molto pesanti, andremo a leggere i dati solo all’occorrenza.

LOB

DOWNLOAD CODICE DELL’ARTICOLO

AlphaShopV6

AlphaShopV7

Il progetto AlphaShopV6.zip è per il DBMS SQL Server mentre AlphaShopV7.zip è per MySQL.

IL LINGUAGGIO JAVA

IL LINGUAGGIO JAVA

LINK AI POST PRECEDENTI

SPRING FRAMEWORK