BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Articles Simplifiez-Vous La Vie Autour Des Données Avec Java Et Jakarta EE

Simplifiez-Vous La Vie Autour Des Données Avec Java Et Jakarta EE

Favoris

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.

 

Au sujet de l’Auteur

Evaluer cet article

Pertinence
Style

Contenu Éducatif

Bonjour étranger!

Vous devez créer un compte InfoQ ou cliquez sur pour déposer des commentaires. Mais il y a bien d'autres avantages à s'enregistrer.

Tirez le meilleur d'InfoQ

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

Commentaires de la Communauté

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

Html autorisé: a,b,br,blockquote,i,li,pre,u,ul,p

BT