Spring Web MVC

EL GHAYAM
Introduction
●
Spring MVC est une couche de framework Spring qui a pour mission le développement
web.
●
Se base sur le pattern de conception MVC (Model-View-Controller) pour assurer une
séparation des taches.
●
Utilise le protocole HTTP : chaque requête de l’utilisateur représente une action à traiter
par le framework.
●
Relier chaque requête à une méthode.
●
Spring MVC adopte le mécanisme de l’injection de dépendance.
●
Permet d’utiliser une variété de technologies relatives aux vues : Freemarker,
Thymeleaf et bien évidemment JSP (Java Server Page).
MVC
●
MVC est un pattron de conception qui permet de
définir une application selon trois composants
logiques :
●
Model : représente les données de l’application.
N’est pas concerné de comment présenter les
données à l’utilisateur. Examples : Personne,
Client, Commande, ..
●
View : permet de présenter les données du modèle
à l’utilisateur. Contient l’ensemble des
composants graphiques pour interagir avec
l’application.
●
Controller : accueille les requêes de l’utilisateur.
Souvent sous forme des actions venues d’une vue.
Réagit par l’invocation d’une méthode en utilisant
un modèle. Le résultat est souvent reflétée dans la
vue.
Architecture d’une application web
●
Une application web est pratiquement Serveur d’application (Spring
+Tomcat)
composée de trois parties couches : Client
Web HTTP, HTML
●
Web : Responsable de recevoir la requête et HTML
Spring IOC Container
préparer la réponse en faisant intervenir les
autres couches. Web
Client
●
Métier : représente l’ensemble des Web REST: HTTP, JSON
traitements et des opérations assurés par AngularJS Busines Layer (Métier)
JQuery
l’entreprise. Communique directement avec
le module de stockage des données. Data Access Layer (Dao)
●
DAO (Accès aux données): représente les Client REST: HTTP, JSON
opérations d’accès et de manipulation des Mobile
données. Cette couche pourait être inclue
dans la couche métier.
●
Parfois on décrit une application web par
SGBD
●
Partie backend : tout ce qui est exécuté côté
serveur:
●
Partie frontend : côté client.
Architecture et MVC
Protocole HTTP
●
La communication entre le client et le serveur (couche web) se fait par le protocole
HTTP.
●
La communication est réalisée par l’échange de requête (client) et réponse (serveur).
●
Une requête HTTP peut être envoyée en utilisant l’une des méthodes suivantes:
✔
GET : demander une ressource (une page, une image ou un fichier particulier),
✔
POST : apporter une modification au serveur. Typiquement utilisée pour soumissionner
un formulaire (Envoyer dans la requête des données saisies par l’utilisateur),
✔
PUT : envoyer un fichier du client vers le serveur,
✔
DELETE : demander au serveur de supprimer un document.
✔
HEAD : permet de récupérer les informations sur un document (Type, Capacité, Date
de dernière modification etc…)
Protocole HTTP

●
Une requête HTTP contient :
✔
Une première ligne indiquant :
●
Méthode utilisée pour communiquer avec le serveur : GET, POST, ...
●
URL demandée de l’application,
●
version du protocole 1 ou 2.
✔
Un ensemble de lignes indiquant les entêtes de la requête sous forme de clé : valeur
●
Exemples :
●
Accept : type de contenu accpeté par le browser.
●
Host : la machine client,
●
…
●
Une ligne vide pour séparer les entêtes du corps de la requête.
✔
Le corps de la requete : envoi de données par une commande POST.
Protocole HTTP

o Exemple de requête HTTP : méthode GET o Exemple de requête HTTP : méthode POST
Protocole HTTP

●
Une réponse HTTP contient :
✔
Une ligne de statut :
●
La version du protocole
●
Le code de statut (200, 404, …)
●
La signification du code (Ok, Resource not found, …)
✔
Les champs d’en-tete de la réponse,
●
des informations supplémentaires sur la réponse et/ou le serveur (Content-Type,
Content-Length, ...).
✔
Le corps de la réponse : la resource demandée.
Protocole HTTP

●
Exemple de réponse HTTP :
Protocole HTTP
●
Exemple de communication Client-Serveur :
●
Le client se connete au Serveur : Créer une
Socket en utilisant une adresse IP et un
numéro de port,
●
Le client demande un document : envoie
de requête Http en utilisant la méthode
Get,
●
Le Serveur répond en envoyant le
document avec le code de status = 200 Ok
(ou bien une erreur),
●
Déconnexion : destruction de socket après
le chargement complet du document.
Spring MVC : DispatcherServlet

●
Spring MVC se base sur les API des servelets.
✔
Servelet est classe en Java (Composant Web JEE) qui s’exécute du coté serveur suite à une
requête HTTP de l’utilisateur.
✔
Permet de gérer des requêtes HTTP et de fournir au client une réponse HTTP (sous forme de
code HTML, image, téléchargement d’un fichier, ..),
●
Spring MVC est conçu autour le design pattern Front Controller.
✔
Fournit un mécanisme de manipulation centralisée des requêtes.
●
Dispatcher est la principale servlet qui reçoit toutes les requêtes et les envoie aux spécifiques
composants pour le traitement
●
Accompagné de composants pour la délégation de la manipulation de certains aspects des requêtes
:
●
handler mappings - faire suivre la requête au controleur approprié.
●
view resolvers - trouver la vue correspondant.
DispatcherServlet
●
A la reception d’une requête, le
DispatcherServlet décide sur le controleur
correspondant en communiquant avec le
handler mapping.
✔
L’une des méthodes du controleur est
invoquée.
●
La méthode du controleur utilise un modèle
et retourne une vue, passée en nom, avec le
modèle au DispatcherServlet.
●
Le DispatcherServlet se base sur le view
resolver pour trouver la vue indiquée par son
nom selon la configuration du resolver.
●
Le DispatcherServlet passe le modèle à la
vue
✔
La vue est retournée à l’utilisateur.
DispatcherServlet
<servlet>
●
DispatcherServlet nécessite d’être déclaré et <servlet-name>dispatcher</servlet-name>
<servlet-class>
mappé dans le fichier descripteur de déploiement [Link]
[Link]. </servlet-class>
✔
Peut être aussi déclaré dans une classe java.
<init-param>
●
Contient principalement les éléments suivants : <param-name>
●
Le nom attribué à cette servlet : contextConfigLocation
</param-name>
<servlet-name></servlet-name> <param-value>
●
Le nom de la classe de la servlet en indiquant /WEB-INF/[Link]
le package d’appartenance : </param-value>
</init-param>
<servlet-class></servlet-class>
✔
L’URL mappé à cette servlet : <load-on-startup>1</load-on-startup>
<url-pattern>/</url-pattern>. </servlet>
✔
<init-param/> indique le fichier context <servlet-mapping>
d’application : le conteneur web des servlets. <servlet-name>springmvc</servlet-name>
✔
Si c’est pas indiqué, [Link] est <url-pattern>/</url-pattern>
</servlet-mapping>
considéré par défaut.
WebApplicationContext

●
WebApplicationContext est le conteneur
servlet indiquant les différentes ressources de
l’application en tant que des beans :
●
Initialisé par le DispatcherServlet.
●
Peut être déclaré à base de XML ou Java [Link] :
<beans … >
●
L’exemple suivant contient
<context:component-scan base-package="controllers" />
✔
context:component-scan : indique que <bean class="[Link].
les beans de l’application web InternalResourceViewResolver">
(controleurs) se situent dans le package <property name="prefix" value="/WEB-
controllers. INF/views/" />
<property name="suffix" value=".jsp" />
✔
ViewResolver : utilise </bean>
InternalResourceViewResolver pour
</beans>
trouver les vues dans le répertoire /WEB-
INF/views ayant l’extension jsp.
Controlleur
@Controller
●
La classe qui répond aux requêtes en communiquant
@RequestMapping(value = "/hello")
avec la couche métier. @Controller
●
Un controlleur est reconnu par l’annotation public class HelloReaderController {
@Controller.
public ModelAndView sayHello() {
●
@RequestMapping indique la valeur de l’url qui ModelAndView mv = new ModelAndView();
s’accorde pour invoquer une méthode. [Link]("message", "Hello !!!");
[Link]("hello");
✔
Réalisé par le handler mapping :
return mv;
RequestMappingHandlerMapping. }
●
La méthode a pour rôle de préparer un modèle et de
retourner une vue. }
✔
ModelAndView : une classe détenant un modèle et
une vue.
✔
Pratiquement on utilise la classe Model : une
collection de clé-valeur.
Controlleur
@RestController
●
Utilisé pour rendre la partie backend indépendante de la partie frontend.
●
Le serveur ne s’occupe pas de la partie frontend,
●
Le serveur se limite à fournir les données demandées en brut et réalise les actions coté serveur.

●
Le retour des données-résultats est sous forme de JSON (JavaScript Object Notation) :
”a standard text-based format for representing structured data based on JavaScript object
syntax”.

●
JSON est structuré selon : “clé” : “valeur”.
“valeur” peut être un string, un nombre, un objet, un tableau, un boolean ou null.

●
Une application/API Restful (Representational State Transfer) : un style architectural qui se
base sur des requêtes HTTP pour accéder et gérer les données.
●
Trop utile pour le cloud, l’IoT, les applications mobiles.
Controlleur
@RestController
●
Une spécialisation de @Controller pour définir un controlleur Restful.
●
Equivalent à utiliser @Controller + @ResponseBody.
●
@ResponseBody : l’objet passé à HttpResponse est automatiquement sérialisé.
●
Utilisé conjointement avec RequestBody et ResponseEntity.
●
@RequestBody : permet de dé-sérialiser automatiquement un objet, reçu depuis HttpRequest.
●
Cet objet est supposé envoyé selon le format JSON.
●
Il fait le traitement inverse de ResponseBody.
●
@ResponseEntity représente une réponse HTTP dans laquelle on peut indiquer les headers, le corps et le
code de status de la réponse. Hérite de HttpEntity
●
Les constructeurs :
- ResponseEntity(HttpStatus statusCode)
- ResponseEntity(MultiValueMap<String,String> headers, HttpStatus statusCode)
- ResponseEntity(T body, HttpStatus statusCode)
- ResponseEntity(T body, MultiValueMap<String,String> headers, HttpStatus statusCode)
Controlleur
@RestController

@GetMapping("/hello")
@RestController
public class HelloReaderController {

public ResponseEntity<UnObjet> repondre () {

HttpHeaders headers = new HttpHeaders();

return new ResponseEntity<UnObjet>(obj, responseHeaders, [Link]);

// return [Link]().headers(headers).body(obj);
}

}
Controlleur
@RestController

@DeleteMapping("/supprimerRest/{id}")
public ResponseEntity<Void> supprimerUnite(@PathVariable long id) {

UniteMesure unite = [Link](id);

if(unite != null) {
try {
[Link](id);
}
catch(Exception e) { // cette unite est utilisé par un article
return [Link]().build();
}
return new ResponseEntity<Void>([Link]);
}
else { // unite deja supprimée
return [Link](900).build();
}

}
Controlleur
@RestController

public ResponseEntity<Object> postAddUniteMesure(@RequestBody UniteMesure unite) {

HashMap<String, Boolean> errSrv = new HashMap<>();

if(!verifierDonnees(unite, errSrv)) {
return new ResponseEntity<Object>(errSrv,HttpStatus.INTERNAL_SERVER_ERROR);
}

UniteMesure savedUnite = [Link](unite);

return new ResponseEntity<Object>(savedUnite, [Link]);