MVC

MVC signifie Model – View – Controller. C’est un patron architectural qui sépare les responsabilités d’une application :

  • Modèle (Model) : représente les données et les règles métier du domaine (entités, validations, calculs).
  • Vue (View) : s’occupe de la présentation pour l’utilisateur (page HTML, JSON en REST, PDF, etc.).
  • Contrôleur (Controller) : reçoit la requête, valide les entrées, orchestre le traitement vers le modèle (via un service), puis choisit la vue/réponse.

Idée clé : le contrôleur n’embarque pas la logique métier, la vue n’accède pas à la base de données, et le modèle est indépendant de la présentation.

MVC MVC

Le cycle d’une requête (exemple)

  1. Le client envoie GET /produits?categorie=camera.
  2. Le Controller correspond à la route et valide les paramètres.
  3. Il appelle le Model (souvent via un service métier) pour exécuter la règle.
  4. Le Model lit/écrit en BD (via un composant d’accès aux données).
  5. Le Model retourne un résultat (ex. liste de produits).
  6. Le Controller choisit la View qui formate la sortie (HTML ou JSON en REST) et renvoie la réponse HTTP (codes 200/201/404…).

Pourquoi utiliser MVC ?

  • Lisibilité : on sait où mettre le code (cloisonnement clair).
  • Testabilité : tester le Model sans HTTP, tester le Controller avec des mocks du service.
  • Évolutivité : on peut faire évoluer l’UI sans casser le métier, et inversement.

Les bonnes pratiques (niveau cours)

  • Conserver un flux à sens unique : Controller → Service/Model → (Données) → View.
  • Introduire un service métier quand les règles deviennent nombreuses.
  • Jamais d’accès BD dans la View ; peu de logique dans le Controller (orchestration seulement).

Où se place MVC selon l’architecture ?**

  • Monolithique : tout est déployé ensemble, MVC structure l’intérieur (couches claires).
  • N-tiers : l’API REST est la frontière Frontend ↔ Backend ; à l’intérieur du backend, on applique MVC.
  • Microservices : chaque service applique son mini-MVC (contrôleur REST, service/métier, accès données).

À suivre : mise en place de Spring Boot (Spring Web MVC) avec un contrôleur REST, un service métier et un repository JPA.

En pratique

Spring est un écosystème Java (injection de dépendances, AOP, données, web…) pour structurer proprement une application. Spring Boot en est la version « turbo » : il fournit l’auto-configuration, des dépendances starters et une exécution prête à l’emploi (embedded Tomcat), ce qui permet de lancer un service web REST en quelques fichiers.

Avec Spring Web MVC, les rôles MVC se mappent à des annotations simples :

  • @Controller / @RestController → controller (reçoit la requête et renvoie la réponse avec les codes HTTP)
  • @Service → service métier (règles et orchestration)
  • @Repository → accès aux données (via JPA/Hibernate)
  1. Le Model (côté Spring)
    À travers ce cours, on appelle Model tout ce qui représente le domaine :
    les entités persistées (JPA), parfois des DTO pour l’API, et les règles implémentées en services.
  • Entité JPA : classe Java mappée à une table BD (id, colonnes).
  • Repository : interface pour CRUD (hérite de JpaRepository).
  • Service : où résident les règles métier (validation, scénarios).
  1. Le Contrôleur (côté Spring)
    Le Contrôleur reçoit la requête HTTP, valide les entrées, appelle le service métier puis renvoie la réponse (corps + code HTTP).
    Annotations clés :
  • @RestController + @RequestMapping("/api/…") : contrôleur REST (réponse JSON par défaut).
  • @GetMapping, @PostMapping, @PutMapping, @PatchMapping, @DeleteMapping : routes par verbe HTTP.
  • @PathVariable, @RequestParam, @RequestBody, @Valid : lier et valider les données d’entrée.
  • ResponseEntity<?> : contrôler le code (200/201/204/404…) et les en-têtes (ex. Location).
  1. La Vue (côté Spring)
    La Vue est ce que l’on renvoie au client. Avec une API REST, la vue est généralement du JSON ; dans une app serveur rendue côté serveur, ce sera un template (ex. Thymeleaf).