Persistance

Ajout de la persistance

Dans l’activité précédente nous avons commencé à prendre en main Vert.x et ajouté des routes sans persistance pour notre application. Maintenant nous allons ajouter une persistance pour nos entités en connectant notre application à une base de données.

Pour la suite de l’application, nous utiliserons la base de données dont les schémas conceptuel et logique sont les suivants :

La base pour le projet

Vous trouverez en dessous une archive de code contenant les sources de la base du projet. En plus des concepts vus lors de la séance précédente nous avons ajouté la partie persistance et une base de données. Téléchargez l’archive, dézippez la et ouvrez le dossier dans VS Code.

Comme dans l’activité de BDD, une fois les services lancés avec docker compose up -d vous pourrez accéder à une interface de gestion de la base de données ici, le Système est PostgreSQL, les identifiant, mot de passe et base de données sont test.

Pour la suite nous vous recommandons de coder directement des handlers qui intègrent la persistance et de vous répartir le travail pour avancer sur plusieurs routes en même temps.

Pensez également associer l’EntityManager à vos handlers pour que ceux-ci puissent interagir avec la base de données. Regardez comment cela est fait dans ExampleHandler.java.

Structure des nouveaux codes

Comme à la session précédente le code est réparti en deux packages, model contient les classes des entités gérées par la base de données et server la logique du serveur et les handlers. Vous n’aurez pas besoin d’ajouter d’attributs aux classes du modèle mais vous pouvez ajouter de nouvelles méthodes pour éviter des redondances dans votre code (ex. en ajoutant des méthodes toJSON()).

Vous pouvez aussi voir, dans le package server deux handlers, dont GridHandler.java qui utilise la base de données pour retourner les ID des grilles existantes. En plus des méthodes vues lors de l’activité 5 de BDD, vous pouvez constater l’utilisation de requête SQL brutes.

List<Integer> grids = db.createNativeQuery("SELECT g.id from grid as g").getResultList();

Ici, des requêtes SQL directes sont effectuées depuis le code Java. Ces requêtes natives sont très flexibles car vous pouvez écrire n’importe quel code SQL. Cependant, il peut être compliqué de récupérer des objets de notre package model avec. C’est pourquoi nous vous conseillons de n’utiliser ces requêtes natives que lorsque vous souhaitez récupérer des données primitives (entiers, flottants, chaines de caractères, …). Typiquement, pour les routes /persons, /sensors, /grids, /grid/:id/production ou /grid/:id/consumption.

Lorsque vous avez besoin de récupérer un objet, nous vous conseillons d’utiliser la méthode find() vue dans l’activité 5 de BDD. La méthode find() fait quelque chose de similaire au bloc de code suivant :

Sensor s = (Sensor) db
    .createNativeQuery("SELECT * FROM sensor WHERE id = ?", Sensor.class)
    .setParameter(1, 4)
    .getSingleResult();

Notez le ? dans la requête, c’est un paramètre qui sera remplacé par une valeur avec la méthode setParameter(index, value). Celle-ci sert à se protéger des attaques par injection SQL. En effet, lorsque nous préparons une requête de cette façon, le système s’assure que les valeurs que nous injectons sont bien formées et ne causent pas de soucis.

Enfin, l’appel à la méthode getSingleResult() exécute la requête et nous retourne la valeur correspondante. Si la requête retourne plusieurs résultats, il faut utiliser la méthode getResultList() qui retourne une liste contenant les résultats.

La suite

C’est à vous de continuez à implémenter les routes de façon à ce que votre backend se comporte correctement. Les routes sont spécifiées ici.