Aller au contenu

Semaine 3 : JOUR 3 – PostgreSQL & JDBC - Architecture applicative

Formation Java / Spring Boot pour développeur.euse.s COBOL

Objectifs

À l’issue de cette journée, vous serez capable :

Aujourd’hui, on ne découvre presque aucun nouveau concept, on réorganise intelligemment ce que vous savez déjà. Nous allons quand même installer et découvrir PostGreSQL et/ou MySQL.

Introduction à PostGreSQL

Installation et découverte de PostgreSQL

Introduction à JDBC par l’exemple

Version de démonstration avec MySQL

Version mise à jour pour MySQL 8

Version de démonstration avec PostgreSQL

Exemple complet JDBC sans Hibernate ni Spring Boot avec PostgreSQL

En tenant utilisant l’une ou l’autre des versions ci-dessus, vous pouvez mettre en place le Design Pattern DAO avec un CRUD pour une table en base de données.

Mise en contexte (Architecture Java)

On sépare explicitement :

  1. Orchestration
  2. Logique métier
  3. Accès aux données

Pas pour compliquer les choses, mais pour maintenir, tester et faire évoluer notre application.

1) Notion clé : séparation des responsabilités

Principe fondamental

Une classe = une responsabilité principale

Ce principe est :

2) Les couches classiques d’une application Java

Vue simplifiée (sans Spring Boot)

Correspondance COBOL (analogie)

COBOL Java
Programme principal Main / Application
Paragraphes métier Services
Programmes accès fichiers DAO
Structures DATA DIVISION Modèle objet

3) Architecture (avant Spring)

com.banque
├── app            (orchestration)
├── service        (logique métier)
├── domain         (objets métier)
├── dao            (accès données)
└── util           (technique)

Cette structure sera quasi identique en Spring Boot.

4) Le rôle de chaque couche

4.1 Couche App (orchestration)

public class BanqueApplication {
    public static void main(String[] args) {
        // orchestration uniquement
    }
}

4.2 Couche Domaine (objets métier)

Aucune dépendance technique

4.3 Couche Service (logique métier)

Exemple :

public class VirementService {
    public void virer(Compte source, Compte cible, BigDecimal montant) {
        source.debiter(montant);
        cible.crediter(montant);
    }
}

4.4 Couche DAO (accès aux données)

Déjà vu avec CompteDAO

5) Ce qu’on NE DOIT PLUS FAIRE (important)

Ces erreurs sont très fréquentes lorsqu’on débute.

PARTIE CENTRALE – REFACTORISATION COBOL vers JAVA OBJET

6) Exemple de traitement COBOL typique

READ COMPTE
IF SOLDE < MONTANT
    MOVE "KO" TO CODE-RETOUR
ELSE
    SUBTRACT MONTANT FROM SOLDE
    WRITE COMPTE
END-IF

Tout est mélangé :

7) Étape 1 – Identifier les responsabilités

8) Étape 2 – Traduction naïve en Java

if (compte.getSolde().compareTo(montant) < 0) {
    System.out.println("Erreur");
} else {
    compte.setSolde(compte.getSolde().subtract(montant));
    dao.save(compte);
}

Mauvaise version :

9) Étape 3 – Refactorisation orientée objet

Dans l’objet Compte

public void debiter(BigDecimal montant) {
    if (solde.compareTo(montant) < 0) {
        throw new DebitInterditException("Solde insuffisant");
    }
    solde = solde.subtract(montant);
}

Dans le service métier

public class CompteService {

    private CompteDAO dao;

    public CompteService(CompteDAO dao) {
        this.dao = dao;
    }

    public void debiterCompte(String numero, BigDecimal montant) {
        Compte compte = dao.trouverParNumero(numero);
        compte.debiter(montant);
        dao.sauvegarder(compte);
    }
}

Dans l’orchestration

try {
    service.debiterCompte("FR001", new BigDecimal("200"));
} catch (DebitInterditException e) {
    System.out.println(e.getMessage());
}

10) Bilan de la refactorisation

✔ règles métier dans les objets
✔ orchestration claire
✔ accès données isolé
✔ code testable
✔ évolution facilitée

C’est exactement ce qu’attend une équipe Java.

11) Refactorisation complète

TP 1 – Refactoriser un traitement monolithique

Consignes : reprendre un ancien TP des semaines 1 ou 2

  1. Partir d’un main() très chargé
  2. Identifier les responsabilités
  3. Créer :
    • un service métier
    • des objets responsables
    • un DAO
  4. Supprimer toute logique métier de main()

TP 2 – Ajouter un nouveau scénario sans tout casser

Consigne :

12) Pourquoi cette architecture est essentielle pour la suite

Parce que :

Si l’architecture est mauvaise, Spring amplifie les problèmes.

Erreurs fréquentes

  1. Recréer un programme monolithique en Java
  2. Mettre toute la logique dans les services
  3. Utiliser des setters pour tout
  4. Coupler service et DAO trop fortement
  5. Mélanger affichage et métier
  6. Créer des services “fourre-tout”
  7. Refuser la séparation par habitude COBOL
  8. Ne pas renommer les classes après refactorisation
  9. Vouloir optimiser trop tôt
  10. Ne pas tester manuellement les scénarios

Avancement de la compréhesion d’un projet Java

À ce stade, un projet est :

Synthèse de la journée

Vous savez maintenant :

Cette journée est fondamentale pour la réussite de la suite…

Pour demain

On abordera :

```