Netapsys Blog

Le 10 juin 2010, Spring User Group FR (SUGF) a organisé une conférence sur les styles d'injection de dépendances via Spring. La session a été animée par Chris Beams. L'objectif de ce post est d'exposer les parties essentielles de la conférence:

• Choisir un style de DI (Dependency Injection)
  
• Exemples de styles de DI.
  
  

Speaker: Chris Beams

Chris Beams est ingénieur sénior chez SpringSource depuis 2007. Il fait partie des développeurs de Spring Core et de quelques autres modules de Spring. Il anime des conférences et des formations sur les différents produits de Spring.

Comment choisir une méthode?

Le choix d'une méthode de DI repose sur différentes caractéristiques:

• Interne /Externe au code,
  
• Implicite ou explicite
  
• Type-safe
  
• Portabilité etc.
  

Le choix d'un style dépend des propriétés validées. Si nous souhaitons, par exemple, que notre code soit portable, que la configuration soit externe, nous utiliserons le fichier XML et non pas les annotations.

Les styles de DI

Dans une seconde partie Chris nous explique les différents styles de DI via des exemples pratiques.
Nous pouvons retrouver les exemples de styles suivants:

• Le fichier de configuration XML:
  

L'injection par XML reste la méthode de configuration la plus utilisée. Ce style est externe, explicite et portable.

• Injection par annotation:
  

Ce style est facile à développer et maintenable. Comme annotations intéressantes, nous retrouvons, @Component, @Autowired etc. Mais, le code n'est pas portable.


En outre, Spring offre un ensemble de méthodes de DI. Chaque méthode a des avantages et des inconvénients. Dans un premier temps, nous devons cibler les caractéristiques importantes comme la portabilité et les performances. Ensuite nous choisissons le style de DI qui répond le plus à notre demande.

Ce billet aborde l'aspect purement technique de mise en oeuvre de l'agilité dans le développement d'applications robustes.
Il s'inscrit dans la continuité du séminaire de Netapsys sur le thème "Agile & more efficient".
Il présente les tests JUnit 4.x et EasyMock sous Spring afin de concrétiser "être agile".
EasyMock permet de simuler l'accès aux fonctionnalités des couches applicatives, par exemple la couche DAO.
Un des piliers de l'agilité est TDD (Test Driven Development).
Le TDD est une approche évolutive de réalisation de projets basés sur les tests avant même de produire du code effectif.
TDD combine le TFD (Test First development) et le refactoring afin d'arriver à affiner / définir les spécifications.
Easymock et JUnit constituent donc les briques afin de réaliser le TDD via les tests unitaires et d'intégration.
En fait, les tests unitaires sont faciles à mettre en place mais les tests d'intégration restent encore difficiles.
Et le coût de réaliser les tests d'intégration est pesant.
Et EasyMock permet la mise en place des tests sans pour autant avoir développé une ligne de code d'implémentation des couches applicatives. Tous ces aspects vont être explicités ci-dessous.

L'objet de ce billet, en deux parties, est de comparer l'annotation standard @Resource du package javax.annotation.Resource à celle de
spring @Autowired du package org.springframework.beans.factory.annotation.
Nous verrons les situations où nous sommes obligés de favoriser les annotations standards.

L'utilisation des annotations réduit considérablement la verbosité des fichiers de configuration de Spring.
C'est aussi le même constat pour d'autres frameworks.
En effet, le principe "convention Over configuration" participe à cette diffusion.
Certes, les "pour" et les "contre" ne manqueront pas d'arguments pour débattre.
Mais ceci n'est pas l'objet de ce billet.
L'objectif ici est de comparer ces deux types d'annotations.
Pour cela, nous nous appuyons sur un projet java simple, sans maven, que vous pouvez créer sous Eclipse en suivant les étapes décrites ci-après.
Nous écrivons d'abord un projet avec les annotations de Spring puis nous illustrons les difficultés qui nous amèneront à introduire les annotations standards.

L'objet de ce billet: Illustrer avec un exemple assez complet la mise en pratique du web service REST (JAX-RS) s'appuyant sur l'implémentation RestEasy de JBoss avec Spring 2.5.
L'exemple repose sur les briques (api) suivantes. Notez bien la version lorsqu'elle est mentionnée.

• RestEasy: L'implémentation Jboss de jax-rs (JSR 311),
  
• Spring 2.5 et les annotations,
  
• Hibernate pour la partie persistence
  
• L'api Dozer v4.0 pour les DTO (Data Transfert Objetc) ou VO((Value Object).
  
• Junit 4.4,
• HttpUnit,
  
• XMLUnit.
  

Nota:La version Dozer 4.0 a renommé complètement ses packages. Certains tutos sur le web sont donc caduques.
C'est à la fin de l'étape 5 que nous détaillons l'emploi de l'api Dozer.

Quelques repères:
REST (Representational State Transfer) développé par Roy Fielding qui est l’un des fondateurs du protocol HTTP.
JSR 311 est la spec JAX-RS: Java API for RESTful Web Service. Finalisée en mars 2008.

Les CINQ principes de REST

• P1: Tout est ressource, un identifiant unique à chaque ressource (http://localhost:8888/clients/2 pointe sur le client ayant id=2),
  
• P2: Utiliser les méthodes HTTP (HEAD/GET/POST/PUT/DELETE). Et les erreurs standards HTTP,
  
• P3: Les échanges avec plusieurs représentations ( xml,(x)html, json,..),
  
• P4: Échanges sans état (stateless),
  
• P5: Lier les ressources entre elles.
  

PRÉ-REQUIS: Java5.

En quatre actes, nous allons illustrer la puissance du framework de validation de Spring sans écrire la moindre classe de validation.
En effet, quelques annotations dans vos beans (POJO), trois lignes de configuration et une ligne de code java; et le tour est joué! Le résultat obtenu est impressionnant!
Vos objets sont validés. De plus, la validation est faite côté serveur et client.
Nous détaillerons tout cela sur un exemple intéressant un peu plus loin.
Ma découverte du framework de validation de Spring me fait dire :
Avec Spring, la vie des développeurs (et des chefs de projet) devient un fleuve tranquille de bonnes pratiques même si l'apprentissage, lui, est loin de l'être!

Sans rentrer dans le débat sur la nécessité de valider les objets et du côté client et du côté serveur, ce framework concilie et satisfait les deux avis.


La démonstration qui va être donnée contient deux projets:
- Le premier, projet web Spring MVC avec maven, détaille comment valider, côté client et serveur, nos objets avec les meilleures pratiques.
- Le second, projet java standalone, illustre un certain nombre d'annotations du framework de validation avec peu de lignes de configuration xml.
Et, le tout avec très peu de code java et en recourant aux validateurs prédéfinis de ce framework.
Le résultat est déconcertant!
Ce framework nous épargne des dizaines de lignes de code java (sans parler du temps à consacrer à les tester/déboguer!).
La démo ci-après repose et applique les deux grands principes:

• Tout est POJO,
• Séparation des préoccupations.

Passons à la pratique.....
Un seul pré requis nécessaire : connaître le framework de Spring et Spring MVC.

Ce billet a pour objectif de définir la validation et de décrire sa mise en place au sein d’une application spring-mvc utilisant le paramétrage XML.