Points Clés
- Comment simplifier l’utilisation des bases de données avec Jakarta EE
- Connaître la nouvelle spécification Jakarta EE
- Les modèles de bases de données sur l'architecture d'entreprise
L'importance des données dans une application ne fait aucun doute. On parle souvent d'une application sans état, et ce sont les bases de données où l'on délègue l'état de l'application. Si l'architecture est l'esprit, l'information est le cœur.
Cet article couvre les prochaines étapes de Jakarta EE dans le monde des données et ses techniques pour fonctionner plus que comme une simple source de données. En d'autres termes, il s'agit de savoir comment appliquer des pratiques autour de données telles que le référentiel et le CQRS de manière agnostique.
Nous avons JPA depuis un certain temps dans le monde des spécifications pour nous faciliter la vie dans le monde des bases de données relationnelles. Nous sommes heureux de travailler sur une spécification pour faciliter le travail avec NoSQL : Jakarta NoSQL.
Le principe de base de Jakarta NoSQL est de normaliser le comportement, de réduire la charge cognitive lors du changement de base de données et, en même temps, d'être suffisamment extensible pour permettre un comportement spécifique d'un fournisseur particulier. En ce moment, nous avons le plaisir d'annoncer une nouvelle version, Jakarta NoSQL Version 1.0.0-b4.
Jakarta NoSQL Version 1.0.0-b4
Cette version comporte plusieurs mises à jour de la bibliothèque, des corrections de bugs et deux nouvelles fonctionnalités. Un modèle de générateur est inclus pour créer et combiner des conditions dans la requête pour en mettre une en évidence. Ainsi, Jakarta NoSQL a deux approches pour créer une requête sur la base de données : utiliser une API fluide et utiliser un modèle de générateur. Nous n'aborderons pas la différence entre ce modèle ici, mais vous pouvez aller plus loin dans mon article intitulé "Fluent-API : Créer un code plus simple et plus intuitif avec une API Fluent.".
Pour illustrer cette ressource, nous allons créer une entité Worker où ce Worker aura cinq attributs : id, name, city, age et gender. Nous utiliserons MongoDB comme base de données.
La première étape consiste à faire fonctionner une base de données MongoDB. Vous pouvez vous faciliter la tâche avec Docker en exécutant la commande suivante:
docker run -d --name mongodb-instance -p 27017:27017 mongo
L'étape suivante consiste à créer un projet Java SE simple dans lequel nous inclurons la configuration minimale requise pour exécuter les applications CDI, JSONB et Eclipse Microprofile Configurations.
De plus, nous inclurons JNoSQL, l'implémentation de référence de Jakarta NoSQL. Une nouveauté de cette version est l'extension mongodb, où vous pouvez exploiter un comportement plus particulier de ce fournisseur NoSQL.
<dependency>
<groupId>org.eclipse.jnosql.mapping</groupId>
<artifactId>mongodb-extension</artifactId>
<version>${project.version}</version>
</dependency>
Pour la connexion de l'application à la base de données, Jakarta NoSQL dépend de la configuration Eclipse MicroProfile pour mettre en œuvre un des douze facteurs, principalement celui de la configuration.
Nous allons l'injecter et le rendre disponible pour CDI.
@ApplicationScoped
public class MongoDBProducer {
@Inject
@ConfigProperty(name = "document")
private DocumentCollectionManager manager;
@Produces
public MongoDBDocumentCollectionManager getManager() {
return (MongoDBDocumentCollectionManager) manager;
}
public void destroy(@Disposes DocumentCollectionManager manager) {
manager.close();
}
}
Nous allons créer la connexion MongoDB. Sans mot de passe ni utilisateur, l'avantage d'une configuration réinscriptible est que nous pouvons mettre plusieurs propriétés en production qui n'ont pas de sens pour s'exécuter localement.
document=document
document.database=olympus
document.settings.jakarta.nosql.host=localhost:27017
document.provider=org.eclipse.jnosql.communication.mongodb.document.MongoDBDocumentConfiguration
Nous avons la configuration du projet; ensuite, nous définirons le modèle d'entité avec l'entité Worker. Ici, nous pouvons voir la similitude avec JPA. La spécification essaie d'avoir des ressemblances, lorsque cela est possible, pour avoir une entrée accessible pour le développeur Java.
@Entity
public class Worker {
@Id
@Convert(ObjectIdConverter.class)
private String id;
@Column
private String name;
@Column
private String city;
@Column
private int age;
@Column
private int dailyHours;
@Column
private Gender gender;
//…
}
L'étape suivante consiste à créer une requête spécifique, où nous combinerons des conditions booléennes, pour trouver des travailleurs :
-
Par exemple, pour trouver une femme de plus de trente ans ou un homme de plus de trente-cinq ans.
public class App10 {
public static void main(String[] args) {
try (SeContainer container = SeContainerInitializer.newInstance().initialize()) {
Worker poliana = Worker.builder()
.age(30).name("Poliana")
.city("Salvador")
.gender(Gender.FEMALE)
.dailyHours(30).build();
Worker otavio = Worker.builder()
.age(35).name("Otavio")
.city("Salvador")
.gender(Gender.MALE)
.dailyHours(30).build();
DocumentTemplate template = container.select(DocumentTemplate.class).get();
template.insert(Arrays.asList(otavio, poliana));
DocumentCondition maleAfterThirty = and(eq("gender", Gender.MALE),
gte("age", 30));
DocumentCondition femaleAfterThirty = and(eq("gender", Gender.FEMALE),
gte("age", 30));
final DocumentQuery query = DocumentQuery.builder()
.from("Worker")
.sort(asc("name"))
.where(or(maleAfterThirty, femaleAfterThirty))
.build();
Stream<Worker> stream = template.select(query);
List<Worker> workers = stream.collect(Collectors.toList());
workers.forEach(System.out::println);
template.delete(Worker.class, otavio.getId());
template.delete(Worker.class, poliana.getId());
}
}
}
Après plusieurs discussions pour avoir plus d'intégration entre JPA et NoSQL, la communauté a décidé de créer une nouvelle spécification pour appliquer ces modèles autour des données : Jakarta Data. Nous l'avons publié au Comité de Jakarta EE.
Quand y aura-t-il une version finale ?
Nous attendons la nouvelle configuration des spécifications de Jakarta. La proposition est de remplacer ce que nous utilisons par MicroProfile Configuration et, espérons-le, de créer une compatibilité avec les deux. D'ici là, nous n'avons pas d'autre choix que d'attendre.
Conclusion
Jakarta NoSQL aide à engager la communauté Java. Il crée plusieurs discussions, telles que la spécification Jakarta Data, se concentrant sur l'importance de la gestion des données, et entame plusieurs discussions pour faciliter la vie du développeur Java.