Après le 1er jour, nous avons pu voir comment séparer convenablement les couches d’une application et une première piste pour modulariser celle-ci. Modularisation grace au modèle de conception Factory Method. Durant le deuxième jour, nous avons vu comment aller plus loin avec l’introduction de l’inversion de contrôle.

Inversion de contrôle

Ces trois lettres ont été longtemps à la mode sur la toile: IoC ou Inversion of Control. Ce modèle est la base du container de Spring et bien que je connaissais déjà Spring avant cette formation, j’ai eu un véritable plaisir à suivre la méthodologie adoptée, à savoir implémenter les concepts de Spring nous-mêmes pour découvrir les avantages à l’utiliser. Lors du premier jour, l’abstraction au moyen du modèle Factory Method a permis de bien délimiter les différentes couches applicatives et de maintenir une certaine indépendance entre elles.
Avant d’arriver concrètement à l’inversion de contrôle il nous a fallu élever à un niveau encore supérieur nos factories. Une Factory Application. Suite à cette refactorisation, nous nous retrouvons avec plus qu’une seule Factory utilisée pour récupérer chaque couche applicative (cf. schéma).

L’inversion de contrôle trouve tout son sens à partir de là. Puisqu’il est possible d’avoir une seule Factory pour chaque module, pourquoi ne pas en externaliser l’implémentation et la gestion afin de développer nos applications de manière modulaire? C’est ce que Spring fait (entre autre).

Le reste de la journée a été passée à implémenter l’étude de cas en utilisant Spring et en intégrant une Datasource. L’objectif de cette retrospective n’est pas de montrer du code mais plutôt d’insister sur la conception. Je publierai plus tard un billet conernant l’utilisation de base de Spring.

OSGI

Notre prof n’a fait qu’une toute petite parenthèse sur OSGI mais c’est un élément qu’il me faut aborder et creuser à l’avenir. Encore un acronyme très à la mode actuellement. Voici un extrait de ce que nous dit Wikipedia sur le sujet:

une plate-forme de services basée sur le langage Java qui peut être gérée de manière distante. Le cœur de cette spécification est un framework (cadriciel) qui définit un modèle de gestion de cycle de vie d’une application, un référentiel (registry) de services, un environnement d’exécution et des modules. Basés sur ce framework, un grand nombre de couches (Layers) OSGI, d’API et de services ont été définis

Plutôt pas mal dans l’objectif de modularisation d’applications… A investiguer…
Ce deuxième jour nous a donc appris ce que faisait Spring en le mettant en oeuvre par nous-même pour ensuite commencer à réellement l’utiliser. L’étude de cas est utilisable en fin de journée mais uniquement en interrogeant une base de données au travers de JDBC. Le dernier jour, nous avons appris à intégrer deux frameworks ultra-connus: Hibernate et Struts.