jeudi 24 mars 2011

Software : Incorporation de Spring Framework




Et si on faisait un peu d'injection de dépendances dans notre projet ?
Rappel : l'idée est d'injecter les objets que l'on souhaite dans d'autres objets (seule contrainte, le respect des interfaces).

Un injecteur bien connu est SPRING. Toutes les injections se font par fichier xml. Quelle utilité allez vous me dire ?


Imaginez un manager d'alarme qui a besoin d'écrire dans le journal de bord de l'application. Ce n'est pas au manager d'alarme d'insérer directement le message. Ce travail est délégué à un manager Journal de Bord, et ce dernier n'est peut être pas encore implémenté (les api oui mais pas l'implémentation) et bien avec Spring on pourra injecter un mock dans le manager d'Alarme, cela permettra de tester : 


                   Notre code java d'alarme sans l'implémentation final du JDB.
                   De ne pas retoucher le code mais seulement la configuration, pour faire un test d'intégration avec le journal de bord. pas mal non ? 


voyons voir comment cela se passe...


Tout d'abord, un coup de snippet maven dans notre pom.xml: 



  <dependency>
<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>
<version>2.5.6</version>
<optional>false</optional>
</dependency>


Puis on modifie notre web.xml pour que Spring s'infiltre dans notre application :
Voici donc les seules lignes à ajouter : 



 <context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/applicationContext.xml</param-value>
</context-param>


<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>



      Maintenant on va faire un tour dans le fichier applicationContext.xml 
On y déclarera tous nos "beans" SPRING, tous pures POJO les uns que les autres. Le scope pourra être précisé pour chaque bean (singleton=une seule instance ou prototype=nouvelle instance à chaque besoin)
Pour nos managers le mode singleton est adapté (pas la peine de créer x instances du même manager), cela tombe bien c'est la config par défaut.

Exemple : 


J'ai déclaré 2 managers (id=parameterManager et id=jdbManager)
dans la classe ParameterManager j'ai 2 attributs ( dao et jdbManager) et bien j'indique à Spring d'injecter dans cette classe parameterDao dans l'attribut dao et jdbManagere dans jdbManager.


Spring va alors chercher un bean nommé parameterDao dans sa configuration, l'instancier et le placer dans parameterManager (qu'il aura lui aussi instancié)




Au niveau code, tout ce que l'on a à faire lorsque que l'on veut utiliser parameterManager c'est de passer par le chargeur de contexte Spring, et oui il faut bien que Spring applique toute la mécanique par la dessus. On est donc obligé de passer par le container SPRING pour obtenir les beans.

Faire un new ParameterManager ne fonctionnera pas, les attributs resteront désespérément null.
Il faut faire la chose suivante :


ServletContext servletContext = servletConfig.getServletContext();
WebApplicationContext wac = WebApplicationContextUtils
.getRequiredWebApplicationContext(servletContext);

ParameterManager pm = (ParameterManager) wac.getBean("parameterManager");

Il existe plusieurs technique de chargement du contexte Spring, par chargement url (on est pas forcément dans un contexte WEB).

Voici une première facette de SPRING appelée IOC (Inversion Of Control), mais Spring offre d'autres fonctionnalités que nous utiliserons pas la suite (Orienté Aspect, Intégration, Batch, ...) je vous invite à consulter le site.





http://www.springsource.org/

Aucun commentaire:

Enregistrer un commentaire