Du Clic Utilisateur à la Base de Données — et Retour

Notes visuelles — Angular & Spring Boot, en français

Angular Spring Boot Base de données Cycle complet

1. Diagramme — Du clic dans l'UI jusqu'à la base de données, et retour

Action utilisateur Composant Angular Service Angular

clic, formulaire → capte l'événement → logique d'appel API

Acteur : Utilisateur / Navigateur Acteur : Component Acteur : Service (@Injectable)

↓
HttpClient Réseau Contrôleur
construit la requête → HTTPS / JSON → reçoit la requête

Acteur : HttpClient + Interceptor Acteur : TCP/IP, navigateur Acteur : @RestController

↓
Service Spring Repository Base de Données
logique métier → accès aux données → exécute la requête SQL

Acteur : @Service Acteur : @Repository (Spring Data JPA) Acteur : MySQL / PostgreSQL

↑ le résultat remonte tout le chemin inverse ↑

Repository → Service Contrôleur Réseau
mappe les résultats → construit la réponse JSON → HTTPS / JSON

Acteur : Entity → DTO Acteur : ResponseEntity + Jackson Acteur : TCP/IP

↓
Service Angular Composant Interface mise à jour
l'Observable reçoit la réponse → met à jour ses données → l'utilisateur voit le résultat

Acteur : HttpClient (subscribe) Acteur : Component Acteur : Template / DOM

Étapes en résumé :

1. L'utilisateur effectue une action dans l'interface (clic, soumission de formulaire).

2. Le composant Angular capte l'événement et appelle une méthode du service associé.
3. Le service utilise HttpClient pour construire la requête HTTP (méthode, URL, corps en JSON).
4. Un intercepteur ajoute d'éventuels en-têtes (ex. jeton d'authentification), puis la requête est envoyée via le réseau (HTTPS/TCP).
5. Le contrôleur Spring Boot (@RestController) reçoit la requête et la transmet à la couche Service.
6. Le Service applique la logique métier puis appelle le Repository pour interroger la base de données.
7. La base de données exécute la requête SQL et retourne les résultats (lignes de la table).
8. Ces résultats sont transformés en objets Java (Entity), puis en DTO si nécessaire.
9. Le contrôleur sérialise la réponse en JSON et la renvoie avec un code de statut HTTP.
10. Angular reçoit la réponse via l'Observable, met à jour les propriétés du composant.
11. Angular détecte le changement (change detection) et met automatiquement à jour l'interface utilisateur — sans rechargement de page.
 2. Les composants d'Angular et de Spring Boot

Côté Angular

Module Composant Template

@NgModule → @Component → vue HTML
regroupe l'application UI + logique

↓ utilise également
Directive Pipe Service
*ngIf, *ngFor transforme l'affichage @Injectable
logique partagée

Un composant Angular est l'unité de base de l'interface : il combine une classe TypeScript (logique), un template HTML (vue) et une feuille de style CSS. Un module regroupe
plusieurs composants, directives et services liés entre eux.

Côté Spring Boot

Contrôleur Service Repository

@RestController → @Service → @Repository
reçoit les requêtes HTTP logique métier accès aux données

↓ manipule
Entity DTO Bean
@Entity objet exposé à l'API tout objet géré par Spring
classe liée à une table

Une application Spring Boot est composée de "composants" au sens large — chaque classe annotée (@Controller, @Service, @Repository) devient un Bean géré
automatiquement par le conteneur Spring, qui s'occupe de les créer et de les relier entre eux.
 3. Qu'est-ce qu'une injection de dépendance ?

Une dépendance est simplement un objet dont une classe a besoin pour fonctionner (par exemple, un composant a besoin d'un service pour récupérer des données).
Normalement, une classe devrait créer elle-même ses dépendances avec le mot-clé new. Le problème : cela crée un couplage fort — une classe est directement liée à une
implémentation précise, ce qui rend le code difficile à tester et à faire évoluer.

L'injection de dépendance (DI) inverse ce contrôle : au lieu que la classe crée ses propres dépendances, c'est un conteneur externe (le framework) qui les crée et les "injecte"
automatiquement, typiquement via le constructeur.

Sans injection Couplage fort

la classe fait : new Service()
✗ difficile à tester / remplacer

↓ avec injection de dépendance ↓

Conteneur DI Objet injecté
Angular Injector / crée & fournit reçu automatiquement
Spring IoC Container par le constructeur

Avantages concrets de l'injection de dépendance :

Découplage : les classes ne connaissent pas les détails d'implémentation de leurs dépendances.
Testabilité : on peut facilement remplacer une dépendance réelle par une version simulée (mock) lors des tests.
Réutilisabilité : un même service/bean peut être partagé entre plusieurs classes sans dupliquer sa création.
Maintenance : changer une implémentation ne nécessite pas de modifier chaque classe qui l'utilise.
 4. La différence entre un composant et un service

Composant

Représente une partie de l'interface visuelle

Contient un template (HTML) et un style (CSS)
Réagit aux actions de l'utilisateur
Décoré par @Component
Ne devrait pas contenir de logique métier lourde
Exemple : StudentListComponent

Service

Contient de la logique réutilisable (pas de vue)

Pas de template ni de style
Gère les appels API, le partage de données, les calculs
Décoré par @Injectable
Peut être injecté dans plusieurs composants
Exemple : StudentService

Composant Service
affiche les données
injecte et utilise → fournit les données

Règle simple : si ça concerne l'affichage → composant. Si ça concerne la donnée ou la logique partagée → service.

Cette même séparation existe côté Spring Boot, mais avec d'autres noms : le contrôleur joue un rôle proche du composant (il gère l'entrée/sortie, ici les requêtes HTTP), tandis
que le service Spring joue exactement le même rôle que le service Angular — centraliser la logique métier, indépendamment de la façon dont elle est appelée.
 5. La liaison des données (Data Binding) — Angular et Spring Boot

Côté Angular — 4 types de liaison

Type Direction Syntaxe Usage

Interpolation Composant → Vue {{ titre }} Afficher une valeur

Property Binding Composant → Vue [src]="image" Définir une propriété HTML

Event Binding Vue → Composant (click)="save()" Réagir à une action utilisateur

Two-way Binding Composant ⇄ Vue [(ngModel)]="nom" Synchroniser un formulaire

La liaison de données Angular relie automatiquement le code TypeScript et le HTML, sans manipulation manuelle du DOM.

Côté Spring Boot — "liaison" des données à l'API

@RequestBody @ResponseBody
JSON entrant → objet Java ↔ (implicite dans @RestController)
objet Java → JSON sortant

Spring Boot n'a pas de "data binding" visuel comme Angular, puisqu'il n'a pas d'interface graphique — mais il fait l'équivalent au niveau des données : il relie automatiquement le
JSON reçu à un objet Java (via @RequestBody), et relie l'objet Java retourné au JSON envoyé (sérialisation automatique par Jackson). On parle aussi de liaison entre une Entity et
une table de base de données via les annotations @Entity, @Column, @Id, qui relient chaque champ Java à une colonne SQL.
 6. Le cycle d'une requête HTTP

Chaque requête HTTP suit toujours le même cycle en quatre grandes phases :

1. Requête 2. Traitement
le client envoie → le serveur reçoit,
méthode + URL + en-têtes + corps route, exécute la logique

↓
3. Réponse 4. Réception
le serveur renvoie → le client interprète
code de statut + corps la réponse et agit

Détail du cycle

1. Ouverture de connexion : le navigateur établit une connexion TCP (souvent réutilisée) avec le serveur.
2. Envoi de la requête : contient une méthode (GET, POST, PUT, DELETE), une URL, des en-têtes (ex. jeton d'authentification), et parfois un corps en JSON.
3. Réception côté serveur : Spring Boot (via Tomcat) reçoit la requête, passe par une chaîne de filtres (sécurité, CORS).
4. Routage : la requête est dirigée vers la bonne méthode du contrôleur selon l'URL et la méthode HTTP.
5. Traitement métier : le contrôleur délègue au service, qui peut interroger la base de données via le repository.
6. Construction de la réponse : un code de statut HTTP est choisi (200, 201, 400, 404, 500...) et les données sont sérialisées en JSON.
7. Retour au client : la réponse traverse à nouveau le réseau jusqu'au navigateur.
8. Traitement côté client : Angular reçoit la réponse via l'Observable, met à jour les données et rafraîchit l'interface.

Codes de statut les plus courants

200 / 201
Succès / Créé

400 / 401 / 404

Erreur du client

500
Erreur serveur
 7. Injection de dépendance — Angular vs Spring Boot

Angular

Conteneur : Injector (hiérarchique)

Déclaration : @Injectable()
Injection via le constructeur du composant/service
Portée possible : racine (root), module, ou composant
Exemple :
constructor(private svc: StudentService) {}

Spring Boot

Conteneur : IoC Container (ApplicationContext)

Déclaration : @Component, @Service, @Repository
Injection via @Autowired ou constructeur
Portée par défaut : singleton (une seule instance)
Exemple :
@Autowired private StudentRepository repo;

Le principe est identique des deux côtés

Conteneur DI Les injecte automatiquement La classe les utilise

crée les objets nécessaires
→ dans le constructeur
→ sans jamais faire "new"

Angular et Spring Boot partagent la même philosophie de conception (Inversion of Control) — ce n'est pas une coïncidence : Angular s'est inspiré des frameworks backend comme Spring pour son propre système
d'injection.
 8. Les contrôleurs et services côté Spring Boot

Le Contrôleur (@RestController)

Le contrôleur est le point d'entrée de l'API : il reçoit les requêtes HTTP et renvoie les réponses. Il ne doit contenir aucune logique métier — son rôle est uniquement de router la
requête vers le bon service et de formater la réponse.

@GetMapping("/students") appelle [Link]() retourne ResponseEntity<List>

reçoit GET
→ →

Le Service (@Service)

Le service contient la logique métier réelle : validations, calculs, règles de gestion, coordination entre plusieurs repositories. C'est la couche qui devrait être testée le plus
rigoureusement, car c'est là que se trouve la valeur métier de l'application.

Reçoit l'appel Applique les règles Appelle le Repository

du contrôleur
→ ex : vérifier l'unicité d'un email
→ pour lire/écrire en base

Pourquoi séparer les deux ?

Aspect Contrôleur Service

Rôle Gérer les requêtes/réponses HTTP Contenir la logique métier

Connaît HTTP ? Oui (codes de statut, headers) Non — indépendant du web

Réutilisable ? Non, lié à une route précise Oui, appelable depuis plusieurs contrôleurs

Testé comment ? Tests d'intégration (API) Tests unitaires (logique pure)

Cette séparation stricte permet de changer la façon dont l'API est exposée (REST, GraphQL...) sans jamais toucher à la logique métier elle-même.