Scarica il documento per vederlo tutto.
Scarica il documento per vederlo tutto.
Scarica il documento per vederlo tutto.
Scarica il documento per vederlo tutto.
Scarica il documento per vederlo tutto.
vuoi
o PayPal
tutte le volte che vuoi
Formattazione del testo
Queste due tabelle verranno mappate attraverso due classi: Categoria.java e Veicolo.java. Ognuno dei quali avrà la stessa struttura della classe mostrata come esempio in precedenza.
La tabella con cardinalità N avrà, nel rispettivo file Java, la seguente notazione:
@ManyToOne @JoinColumn(name='x', referencedColumnName='y') @JsonBackReference(value='id_relazione') @EqualsAndHashCode.Exclude
Dove x indica il nome della colonna relativa alla Foreign key (categoria_pk), mentre y indica il nome della colonna relativa alla chiave primaria della tabella con cardinalità 1 (id_categoria).
La tabella con cardinalità 1 avrà, nel rispettivo file Java, la seguente notazione:
@OneToMany(mappedBy='x', cascade=cascadeType.All, orphanRemove=true) @JsonManagedReference(value='id_relazione')
Dove x indica il nome dell'attributo utilizzato per esprimere l'entità @ManyToOne nella classe.
classe Employee.java.classe che mappa la tabellaemploye
(employe.java
).
11NBSe per scopi progettuali la terza tabella deve contenere altri attributi oltre alle due chiavi esterne, occorre mapparle con la relazione una a molti studiata in precedenza.
4 - REPOSITORY PACKAGE
In questo package specifico devono essere inserite tutte quelle classi (in questo caso interfacce) che eseguono le operazioni CRUD sul database relazionale.
Per rispettare lo standard JPA occorre inserire la seguente sintassi in ogni interfaccia creata:
Di seguito riportiamo un esempio per ogni tipologia.
SELECT
L'annotazione @Query
definisce l'operazione che la funzione sotto indicata deve svolgere.
DELETE
UPDATE parametri
INSERT parametri valori
5 - SERVICES PACKAGE
In questo package vengono inserite tutte le interfacce che definiscono il layer di servizio di una web application.
Si ricorda che questo layer deve contenere tutta la logica di business dell'applicazione.
Ogni interfaccia creata deve avere la sua classe diutenteServices
.
La relativa classe di implementazione sarà:
@Transactional(readOnly=true)
,
transizioni di sola lettura (vale per le query di selezione).
Mentre per le query di inserimento, modifica ed eliminazione occorre inserire sopra il metodo @Transactional
.
CONTROLLER
vengono inserite tutte le API del web services.
Indipendentemente dal tipo di richiesta che si vuole implementare, ogni volta che viene definita una classe controller occorre inserire le seguenti notazioni:
@RestController
@RequestMapping("/path")
Con la prima indichiamo che si tratta di un controller di tipo REST mentre con la seconda definiamo l'URL di base.
@GetMapping(value=
@RequestMapping(value = "/path/{par}", produces = "application/json")
public ResponseEntity<Object> nome-metodo (@PathVariable("par") String val ){
// Corpo funzione
// Eventuale gestioni delle eccezioni
return new ResponseEntity<Object> (dati, HttpStatus.OK);
}
La sintassi {par} non è obbligatoria.
Prima di analizzando gli altri metodi, vediamo come si gestiscono eventuali errori all'interno delle classi controller.
6.2 - Gestione eccezioni
Iniziamo l'analisi creando un nuovo package chiamato exception all'interno dell'applicazione.
Ogni tipo di eccezione deve essere gestito all'interno di una classe presente nel package creato (il programmatore decide quali errori gestire).
Supponiamo di voler gestire l'eccezione NotFoundException, si attiva ogni volta che si applica un filtro ad una lista dati senza ottenere risultati.
Creiamo la relativa calasse all'interno del package creato in precedenza.
metodo all'interno di una specifica classe che converta il messaggio in formato JSON. In questa classe è possibile definire tutti i metodi relativi alla conversione di ogni eccezione. Chiameremo quest'ultima RestExceptionHandler. Di seguito riportiamo la sintassi relativa Conversione messaggio del metodo NotFoundException. Dove nella classe ErrorResponse viene definita la formattazione dell'errore. Per attivare l'eccezione nell'EndPoint di interesse, occorre inserire la seguente EndPoint sintassi.
186.3 - Validazione dati
Prima di inserire e modificare i dati all'interno del database, è buona regola validare e controllare i dati inseriti dall'utente. Questa validazione può essere effettuata sia lato FrontEnd che lato WebServices. Per implementare tale sistema (lato BackEnd) bisogna innanzitutto inserire la classe MessageConfig nel package principale dell'applicazione. In base alle configurazioni effettuate, i messaggi da visualizzare.
In caso divincolo non rispettato, vengono estratti dal file messages_it.properties presente nella cartella src/main/resources.
Attraverso opportune annotazioni messe a disposizione da Hibernate-Validation è possibile verificare se un specifico attributo (dato inserito dall'utente) rispetti un insieme di vincoli. Questi devono essere applicati sugli attributi delle classi di entity.
Di seguito riportiamo le annotazioni messe a disposizione da Hibernate:
Esempio:
Dove con la keyword message indichiamo l'identificativo del messaggio da visualizzare nel momento in cui vengono violati i vincoli. La specifica del messaggio si trova nel file citato in precedenza.
Per attivare e controllare i vincoli specificati, occorre inserire come parametro nei metodi delle classi controller (definiscono gli EndPoint) la notazione @Valid, e nel corpo della funzione uno specifico controllo:
@Autowired private ResourceBundleMessageSource errMessage;
public ResponseEntity<Object> nome-funzione (@Valid,