21. Conclusion

Rappelons ce qui a été présenté dans ce document :

• les bases de la programmation web en Java avec les servlets et les pages JSP
• une introduction à l'architecture MVC
• une introduction à l'architecture 3tier
• une introduction à Spring IoC
• des exemples pour illustrer ces points

Nous pensons que le lecteur arrivé jusqu'ici est prêt pour développer lui-même ses propres applications web en Java. Il est également prêt à aborder d'autres méthodes de développement proches de celles étudiées dans ce document. Rappelons l'architecture des applications web développées ici :

Pour des applications simples, cette architecture est suffisante. Lorsqu'on a écrit plusieurs applications de ce type, on s'aperçoit que les servlets de deux applications différentes :

1. ont le même mécanisme pour déterminer quelle méthode [doAction] il faut exécuter pour traiter l'action demandée par l'utilisateur
2. ne diffèrent en fait que par le contenu de ces méthodes [doAction]

La tentation est alors grande de :

• factoriser le traitement (1) dans une servlet générique ignorante de l'application qui l'utilise
• déléguer le traitement (2) à des classes externes puisque la servlet générique ne sait pas dans quelle application elle est utilisée
• faire le lien entre l'action demandée par l'utilisateur et la classe qui doit la traiter à l'aide d'un fichier de configuration

Des outils, souvent appelés " frameworks ", sont apparus pour apporter les facilités précédentes aux développeurs. Le plus ancien et probablement le plus connu d'entre-eux est Struts (http://struts.apache.org/). Jakarta Struts est un projet de l'Apache Software Foundation (www.apache.org). Ce framework est décrit dans (http://tahe.developpez.com/java/struts/).

Apparu plus récemment, le framework Spring (http://www.springframework.org/) offre des facilités analogues à celles de Struts. C'est en réalité son module Spring MVC. Son utilisation a été décrite dans plusieurs articles (http://tahe.developpez.com/java/springmvc-part1/).

Spring ne s'arrête pas au seul concept MVC de la couche [web] d'une application 3tier. Il est utile même dans des applications situées en-dehors du web.

Ainsi, nous avons terminé notre cours en mettant en oeuvre une architecture MVC dans une architecture 3tier [web, metier, dao] sur un exemple basique de gestion d’une liste de personnes.

Dans la version 1 de l'application, la liste des personnes était maintenue en mémoire et disparaissait au déchargement de l’application web. Dans les autres versions, la liste des personnes est maintenue dans une table de base de données. Nous avons utilisé quatre SGBD différents : Firebird, Postgres, MySQL et SQL Server Express.

Grâce à Spring IoC, la couche [web] de la version 1 a pu être gardée intégralement dans les versions suivantes. Nous avons ainsi montré qu'on pouvait construire des architectures ntier avec des couches indépendantes.

Avec les versions utilisant une base de données, nous avons montré l'apport de Spring pour la construction des couches [dao] et [service]. Grâce à l'intégration de Spring avec iBATIS, nous avons pu construire quatre versions qui ne diffèrent que par leurs fichiers de configuration. La même classe [DaoImplCommon] a été utilisée pour implémenter la couche [dao] dans les quatre versions. Pour gérer un problème spécifique au SGBD Firebird, nous avons été amenés à dériver cette classe mais pas à la modifier.

Enfin, nous avons montré comment Spring nous permettait de gérer les transactions de façon déclarative au niveau de la couche [service].

Le lecteur est encouragé à découvrir la totalité des fonctionnalités offertes par ce produit.