Cours spring

mohamed el haddad
mohamed el haddadEnseignant Chercheur en Informatique at Ecole Nationale des Sciences Appliquées de Tanger em Ecole Nationale des Sciences Appliquées de Tanger
Introduction
Les services et les modules
Les patrons de conception
Les Framework Java
Spring
Claude Duvallet
Université du Havre
UFR Sciences et Techniques
25 rue Philippe Lebon - BP 540
76058 LE HAVRE CEDEX
Claude.Duvallet@gmail.com
http://litis.univ-lehavre.fr/∼duvallet/
Claude Duvallet — 1/42 Framework
Introduction
Les services et les modules
Les patrons de conception
Spring
1 Introduction
2 Les services et les modules
3 Les patrons de conception
Claude Duvallet — 2/42 Framework
Introduction
Les services et les modules
Les patrons de conception
Présentation de Spring (1/2)
SPRING est effectivement un conteneur dit « léger », c’est-à-dire
une infrastructure similaire à un serveur d’application J2EE.
Il prend en charge la création d’objets et la mise en relation
d’objets par l’intermédiaire d’un fichier de configuration qui décrit
les objets à fabriquer et les relations de dépendances entre ces
objets.
Le gros avantage par rapport aux serveurs d’application est
qu’avec SPRING, vos classes n’ont pas besoin d’implémenter
une quelconque interface pour être prises en charge par le
framework (au contraire des serveurs d’applications J2EE et des
EJBs).
C’est en ce sens que SPRING est qualifié de conteneur « léger ».
Claude Duvallet — 3/42 Framework
Introduction
Les services et les modules
Les patrons de conception
Présentation de Spring (2/2)
Outre cette espèce de super fabrique d’objets, SPRING propose
tout un ensemble d’abstractions permettant de gérer entre
autres :
Le mode transactionnel.
L’appel d’EJBs.
La création d’EJBs.
La persistance d’objets
La création d’une interface Web.
L’appel et la création de WebServices.
Pour réaliser tout ceci, SPRING s’appuie sur les principes du
design pattern IoC et sur la programmation par aspects (AOP).
Spring est disponible sous licence Apache 2.0.
Claude Duvallet — 4/42 Framework
Introduction
Les services et les modules
Les patrons de conception
Les services fournis par Spring (1/2)
Spring propose les services suivants (liste non-exhaustive) :
Découplage des composants. Moins d’interdépendances entre
les différents modules.
Rendre plus aisés les tests des applications complexes
c’est-à-dire des applications multicouches.
Diminuer la quantité de code par l’intégration de frameworks tiers
directement dans Spring.
Permettre de mettre en oeuvre facilement la programmation
orientée aspect.
Un système de transactions au niveau métier qui permet par
exemple de faire du "two-phases-commit".
Claude Duvallet — 5/42 Framework
Introduction
Les services et les modules
Les patrons de conception
Les services fournis par Spring (2/2)
Un mécanisme de sécurité.
Pas de dépendances dans le code à l’api Spring lors l’utilisation
de l’injection. Ce qui permet de remplacer une couche sans
impacter les autres.
Une implémentation du design pattern MVC
Un support du protocole RMI. Tant au niveau serveur qu’au
niveau du client.
Déployer et consommer des web-services très facilement.
Echanger des objets par le protocole http.
Claude Duvallet — 6/42 Framework
Introduction
Les services et les modules
Les patrons de conception
Les modules de Spring (1/2)
Le framework est organisé en modules, reposant tous sur le module
Spring Core :
Spring Core : implémente notamment le concept d’inversion de
contrôle (injection de dépendance). Il est également responsable
de la gestion et de la configuration du conteneur.
Spring Context : Ce module étend Spring Core. Il fournit une
sorte de base de données d’objets, permet de charger des
ressources (telles que des fichiers de configuration) ou encore la
propagation d’évènements et la création de contexte comme par
exemple le support de Spring dans un conteneur de Servlet.
Spring AOP : Permet d’intégrer de la programmation orientée
aspect.
Spring DAO : Ce module permet d’abstraire les accès à la base
de données, d’éliminer le code redondant et également
d’abstraire les messages d’erreur spécifiques à chaque vendeur.
Il fournit en outre une gestion des transactions.
Claude Duvallet — 7/42 Framework
Introduction
Les services et les modules
Les patrons de conception
Les modules de Spring (2/2)
Spring ORM : Cette partie permet d’intégrer des frameworks de
mapping Object/Relationnel tel que Hibernate, JDO ou iBatis
avec Spring. La quantité de code économisé par ce package peut
être très impressionnante (ouverture, fermeture de session,
gestion des erreurs)
Spring Web : Ensemble d’utilitaires pour les applications web.
Par exemple une servlet qui démarre le contexte (le conteneur)
au démarrage d’une application web. Permet également d’utiliser
des requêtes http de type multipart. C’est aussi ici que se fait
l’intégration avec le framework Struts.
Spring Web MVC : Implémentation du modèle MVC.
Personnellement j’utilise plutôt Struts mais c’est surtout une
question d’habitude, c’est là la grande force de Spring, rien ne
vous oblige à tout utiliser et vous pouvez tout mélanger. Ce qui
n’est pas forcément une bonne idée mais nous en reparlerons.
Claude Duvallet — 8/42 Framework
Introduction
Les services et les modules
Les patrons de conception
Les patrons de conception
En anglais, on parle de Design Pattern.
Spring repose sur des concepts éprouvés, patrons de conception
et paradigmes, dont les plus connus sont
IoC (Inversion of Control),
le singleton,
la programmation orientée Aspect,
ou encore le modèle de programmation dit "par template".
Ces concepts n’étant pas propre à Spring, ils s’appliquent
également à d’autres frameworks.
Claude Duvallet — 9/42 Framework
Introduction
Les services et les modules
Les patrons de conception
Le modèle de conception "fabrique" (factory) (1/3)
C’est grâce à ce modèle que Spring peut produire des objets
respectant un contrat mais indépendants de leur implémentation.
En réalité, ce modèle est basé sur la notion d’interface et donc de
contrat.
L’idée est simplement d’avoir un point d’entrée unique qui permet
de produire des instances d’objets.
Tout comme une usine produit plusieurs types de voitures, cette
usine a comme caractéristique principale de produire des voitures
De la même façon une fabrique d’objets produira n’importe quel
type d’objet pour peu qu’ils respectent le postulat de base.
Ce postulat (le contrat) pouvant être très vague ou au contraire
très précis.
Claude Duvallet — 10/42 Framework
Introduction
Les services et les modules
Les patrons de conception
Le modèle de conception "fabrique" (factory) (2/3)
Voyons le diagramme de classe :
On remarque facilement que le simple fait de changer la méthode
getForm() permet de passer d’un formulaire de type swing à un
formulaire de type html.
Cela sans avoir le moindre impact sur tout le code qui en découle.
Claude Duvallet — 11/42 Framework
Introduction
Les services et les modules
Les patrons de conception
Le modèle de conception "fabrique" (factory) (3/3)
Nous avons vu ci-dessus que Spring encourageait la
programmation par contrat en voici l’une des nombreuses
raisons.
Bien entendu aussi longtemps que le programmeur chargé de
réaliser la classe SwingForm n’aura pas terminé sa tâche, la
méthode getForm() pourra renvoyer une instance d’une pseudo
implémentation qui renvoie toujours null ou certaines erreurs
remplies en dur pour pouvoir tester et développer les classes
clientes.
Naturellement à lui seul ce pattern ne suffit pas, il faudra lui
adjoindre le singleton et des possibilités de configuration ainsi
que le modèle "bean".
Dès lors le pattern IoC (Inversion of control) sera réalisable.
Claude Duvallet — 12/42 Framework
Introduction
Les services et les modules
Les patrons de conception
Le singleton (1/2)
Il s’agit certainement du patron de conception le plus connu.
En effet, il est (très) utilisé dans beaucoup de domaines.
Ce modèle revient à s’assurer qu’il n’y aura toujours qu’une
instance d’une classe donnée qui sera instanciée dans la
machine virtuelle.
Les objectifs sont simples :
1 Eviter le temps d’instanciation de la classe.
2 Eviter la consommation de mémoire inutile.
Ce modèle impose cependant une contrainte d’importance, la
classe qui fournit le service ne doit pas avoir de notion de
session.
Claude Duvallet — 13/42 Framework
Introduction
Les services et les modules
Les patrons de conception
Le singleton (2/2)
C’est à dire qu’importe le module appelant, le service réagira
toujours de la même façon à paramètre équivalent, il n’a pas de
notion d’historique (ou de session).
Le POJO qui implémentera le service ne doit pas stocker des
informations au niveau de l’objet lui-même.
Pour faire simple il ne faut pas modifier les variables membres au
sein d’une opération (une méthode du service).
Ce concept relativement simple à appréhender, est également
simple à mettre en oeuvre. Du moins en théorie.
L’objectif est de garantir l’unicité de l’instance, pour cela il faut
interdire la création de toute instance en dehors du contrôle de la
classe.
Dans ce but, le constructeur est rendu privé et une méthode qui
retourne une instance de la classe est mise à disposition.
Claude Duvallet — 14/42 Framework
Introduction
Les services et les modules
Les patrons de conception
Le diagramme de classe du Singleton (1/2)
Ce diagramme de classe se traduit par la portion de code
suivante :
public class Singleton {
public static Singleton getInstance() {
if (instance == null) {
instance = new Singleton();
}
return instance;
}
private Singleton() {}
private static Singleton instance;
}
Claude Duvallet — 15/42 Framework
Introduction
Les services et les modules
Les patrons de conception
Le diagramme de classe du Singleton (2/2)
En fait il manque quelque chose pour que ce soit une
implémentation correcte du singleton.
Il s’agit du problème du multithreading, en effet si plusieurs
threads accèdent de façon simultanée à la méthode
getInstance() il se peut que les deux threads détectent en
même temps que le membre est null ce qui conduira à un
problème.
Pour cela, il faudrait déclarer la méthode synchronized ou tout du
moins la portion de code qui manipule l’instance.
C’est justement un des avantages de Spring, vous n’avez plus à
vous soucier de cela, Spring le fait et il le fait très bien.
Claude Duvallet — 16/42 Framework
Introduction
Les services et les modules
Les patrons de conception
L’inversion de contrôle (1/5)
L’inversion de contrôle (IoC : Inversion of Control) ou l’injection de
dépendances (Dependency Injection) est sans doute le concept
central de Spring.
Il s’agit d’un "design pattern" qui a pour objectif de faciliter
l’intégration de composants entre eux.
Le concept est basé sur le fait d’inverser la façon dont sont créés
les objets.
Dans la plupart des cas, si je souhaite créer un objet qui en utilise
un autre je programmerai quelque chose du type :
DBConnexion c=new DBConnexion("jdbc:... ") ;
Pool p=new Pool(c);
//reste du code
SecurityDAO securityDao=new SecurityDao(p);
SecurityBusiness securityBusiness=new securityBusiness(securityDao);
Claude Duvallet — 17/42 Framework
Introduction
Les services et les modules
Les patrons de conception
L’inversion de contrôle (2/5)
À présent votre chef de projet, vous dit : "le client a changé
d’avis, il souhaite utiliser LDAP et non sa base de données pour
l’identification".
Donc, vous devez changer en :
Properties p=new Properties ("ldap.properties");
LDAPConnexion c=new LDAPConnexion(p) ;
//reste du code
SecurityDAO securityDao=new SecurityDao(c);
SecurityBusiness securityBusiness=new securityBusiness(securityDao);
De là, votre chef de projet revient, et vous dit que la direction a
décidé d’en faire un produit standard compatible avec toutes les
bases de données et systèmes d’authentification comme Active
Directory.
Bon, à présent pour vous ça devient moins drôle.
La solution consiste à bien séparer les couches et à utiliser des
interfaces pour se faire.
Claude Duvallet — 18/42 Framework
Introduction
Les services et les modules
Les patrons de conception
L’inversion de contrôle (3/5)
Naturellement, il ne s’agit pas de quelque chose de propre à
Spring, donc dans un premier temps nous aurons :
IConnexion c=new LDAPConnexionImpl () ;
ISecurityDAO securityDao=new LDAPSecurityDaoImpl(c);
ISecurityBusiness securityBusiness=new SecurityBusinessImpl(securityDao);
Maintenant le problème qui se pose est celui de la configuration,
comment configurer de manière simple les drivers et les objets
nécessaires.
Et surtout comment faire pour que le tout s’intègre proprement
dans l’application.
⇒ Entrée en jeu de l’inversion de contrôle.
L’objectif n’est plus de fournir un objet à un autre objet mais au
contraire de faire en sorte que, l’objet dont on a besoin, sache
lui-même ce dont il a besoin.
Et le cas échéant si un des objets nécessaires a lui-même des
dépendances qu’il se débrouille pour les obtenir.
Claude Duvallet — 19/42 Framework
Introduction
Les services et les modules
Les patrons de conception
L’inversion de contrôle (4/5)
Ce qui devrait résulter en :
ISecurityBusiness securityBusiness=IoCContainer.getBean("ISecurityBean);
La méthode getBean est purement formelle pour l’exemple,
l’objectif est de montrer que le code est réduit à sa forme la plus
simple, les dépendances étant déclarées dans la configuration du
conteneur.
Le rôle de cette méthode :
1 Elle résout le nom ISecurityBean dans son arbre de dépendances
et trouve la classe qui l’implémente.
2 Elle en crée une instance (cas d’une injection pas mutateurs).
3 Elle crée les objets dépendants et les définit dans l’objet
ISecurityBean grâce à ses accesseurs.
4 Et enfin, récursivement elle fait de même pour toutes les
dépendances des dépendances.
Claude Duvallet — 20/42 Framework
Introduction
Les services et les modules
Les patrons de conception
L’inversion de contrôle (5/5)
Sur la figure suivante on remarque que les dépendances entre
les couches sont réduites au minimum et que l’on peut facilement
remplacer une implémentation par une autre sans mettre en
danger la stabilité et l’intégrité de l’ensemble.
Claude Duvallet — 21/42 Framework
Introduction
Les services et les modules
Les patrons de conception
La notion d’injection de dépendances
Il existe trois types d’injection :
L’injection par constructeurs.
L’injection par mutateurs (setters).
L’injection d’interface.
Claude Duvallet — 22/42 Framework
Introduction
Les services et les modules
Les patrons de conception
L’injection par constructeurs
Ce type d’injection se fait sur le constructeur, c’est-à-dire que le
constructeur dispose de paramètres pour directement initialiser
tous les membres de la classe.
Object construitComposant(String pNom){
Class c=rechercheLaClassQuiImplemente(pNom) ;
String[] dep= rechercheLesDependance(pNom) ;
Params[] parametresDeConstructeur;
Pour chaque element (composant) de dep
Faire
Object o= construitComposant(composant) ;
Rajouter o à la liste de parametresDeConstructeur ;
Fin Faire
construireClasse( c, parametresDeConstructeur)
}
Claude Duvallet — 23/42 Framework
Introduction
Les services et les modules
Les patrons de conception
L’injection par mutateurs (setters)
Ce type d’injection se fait après une initialisation à l’aide d’un
constructeur sans paramètre puis les différents champs sont
initialisés grâce à des mutateurs.
composant.setNomMembre(o) : le nom setNomMembre est
trouvé grâce à la configuration du composant où il est déclaré : le
membre à initialiser est nomMembre.
Object construitComposant(String pNom){
Class c=rechercheLaClassQuiImplemente(pNom) ;
Object composanr=new c() ;
String[] dep= rechercheLesDependance(pNom) ;
Params[] parametresDeConstructeur;
Pour chaque element (composant) de dep
Faire
Object o= construitComposant(composant) ;
composant.setNomMembre(o) ;
Fin Faire
}
Claude Duvallet — 24/42 Framework
Introduction
Les services et les modules
Les patrons de conception
L’injection d’interface (1/2)
Cette injection se fait sur la base d’une méthode.
Elle est proche de l’injection par mutateurs, la différence se
résume à pouvoir utiliser un autre nom de méthode que ceux du
"design pattern bean".
Pour cela, il faut utiliser une interface afin de définir le nom de la
méthode qui injectera la dépendance.
Object construitComposant(String pNom){
Class c=rechercheLaClassQuiImplemente(pNom) ;
Object composanr=new c() ;
String[] dep= rechercheLesDependance(pNom) ;
Params[] parametresDeConstructeur;
Pour chaque element (composant) de dep
Faire
Object o= construitComposant(composant) ;
composant.méthodeInjection(o) ;
Fin Faire
}
Claude Duvallet — 25/42 Framework
Introduction
Les services et les modules
Les patrons de conception
L’injection d’interface (2/2)
composant.méthodeInjection(o) : le nom
méthodeInjection est trouvé grâce à la configuration du
composant où il est déclaré.
La méthode qui injecte l’objet est définie par une interface.
Dans notre exemple, l’interface serait :
public interface IInjectMethode{
public void méthodeInjection(Object o);
}
L’implémentation du composant se devra alors d’implémenter
cette interface également.
Claude Duvallet — 26/42 Framework
Introduction
Les services et les modules
Les patrons de conception
Programmation orienté Aspect (1/4)
Comme nous pouvons le voir dans la figure suivante, un module
ou composant métier est régulièrement pollué par de multiples
appels à des composants utilitaires externes.
Claude Duvallet — 27/42 Framework
Introduction
Les services et les modules
Les patrons de conception
Programmation orienté Aspect (2/4)
De fait, ces appels rendent le code plus complexe et donc moins
lisible.
Comme chacun sait, un code plus court et donc plus clair
améliore la qualité et la réutilisabilité.
L’utilisation de composants externes implique :
1 Enchevêtrement du code.
2 Faible réutilisabilité.
3 Qualité plus basse due à la complexité du code.
4 Difficulté à faire évoluer.
Claude Duvallet — 28/42 Framework
Introduction
Les services et les modules
Les patrons de conception
Programmation orienté Aspect (3/4)
La solution constituerait donc à externaliser tous les traitements
non relatifs à la logique métier en dehors du composant.
Pour ce faire il faut pouvoir définir des traitements de façon
déclarative ou programmative sur les points clés de l’algorithme.
Typiquement avant ou après une méthode.
Dans la plupart des cas, ce genre de traitements utilitaires se fait
en début ou en fin de méthode, comme par exemple journaliser
les appels ou encore effectuer un commit ou un rollback sur une
transaction.
La démarche est alors la suivante :
1 Décomposition en aspect : Séparer la partie métier de la partie
utilitaire.
2 Programmation de la partie métier : Se concentrer sur la partie
variante.
3 Recomposition des aspects : Définition des aspects.
Claude Duvallet — 29/42 Framework
Introduction
Les services et les modules
Les patrons de conception
Programmation orienté Aspect (4/4)
Il existe deux types de programmation orientée aspect, ces deux
techniques ont chacune des avantages et des inconvénients :
l’approche statique, c’est-à-dire que la connexion entre l’aspect et
la partie métier se fait au moment de la compilation ou après dans
une phase de post-production. Par exemple par manipulation du
bytecode.
⇒ Comme toujours cette méthode intrusive n’est pas forcément la
plus transparente.
L’approche dynamique, dans ce cas, la connexion s’effectue par la
réflexion donc au moment de l’exécution.
⇒ Cette méthode bien que plus transparente est naturellement plus
lente, mais présente l’avantage de pouvoir être reconfigurée sans
recompilation.
Claude Duvallet — 30/42 Framework
Introduction
Les services et les modules
Les patrons de conception
Programmation par template (1/3)
L’objet de ce design pattern est de séparer l’invariant d’un
procédé de sa partie variante.
Dans Spring les templates sont très utilisés dans le cadre de
l’accès aux données et de la gestion des transactions.
Claude Duvallet — 31/42 Framework
Introduction
Les services et les modules
Les patrons de conception
Programmation par template (2/3)
La partie invariante du code est placée dans la partie abstraite de
la classe, ainsi toute classe qui héritera de cette classe abstraite
n’aura qu’à implémenter la partie variante.
Voici un exemple d’utilisation du pattern template tiré de la
documentation de Spring :
tt.execute(new TransactionCallbackWithoutResult() {
protected void doInTransactionWithoutResult(TransactionStatus status) {
updateOperation1();
updateOperation2();
}
});
Claude Duvallet — 32/42 Framework
Introduction
Les services et les modules
Les patrons de conception
Programmation par template (3/3)
Voici comment est déclarée cette classe dans Spring :
public abstract class TransactionCallbackWithoutResult
implements TransactionCallback {
public final Object doInTransaction(TransactionStatus status) {
doInTransactionWithoutResult(status);
return null;
}
protected abstract void doInTransactionWithoutResult(
TransactionStatus status);
}
Ce qui satisfait précisément au schéma de classe déclaré
ci-dessus.
La partie variante est implémentée dans la méthode abstraite, en
l’occurrence ce que vous voulez effectuer dans une transaction.
Claude Duvallet — 33/42 Framework
Introduction
Les services et les modules
Les patrons de conception
Le modèle MVC 1 et 2 (Model View Controller) (1/9)
Ce n’est peut-être pas le concept le plus important dans Spring,
dans la mesure où il a été largement démocratisé par Struts.
Cependant encore trop de programmeurs ont tendance à
mélanger toutes les couches, à mettre des traitements métiers
dans la jsp, ou encore des servlets dans lesquelles ils mélangent
allégrement html, javascript, métier et bien d’autres choses.
Étant donné que l’un des objectifs les plus importants de Spring
est la séparation des couches, la partie MVC et le concept d’un
point de vue général semblent indispensables.
Comme cité précédemment l’objectif est de séparer les couches
et les technologies.
Claude Duvallet — 34/42 Framework
Introduction
Les services et les modules
Les patrons de conception
Le modèle MVC 1 et 2 (Model View Controller) (2/9)
Pour réaliser la séparation entre les couches et les technologies,
le paradigme se divise en trois parties :
Le modèle (Model).
La vue (View).
Le contrôleur (Controller).
La couche d’accès aux données est ignorée ici parce que sous
jacente à la couche métier.
Claude Duvallet — 35/42 Framework
Introduction
Les services et les modules
Les patrons de conception
Le modèle MVC 1 et 2 (Model View Controller) (3/9)
Le modèle (Model) :
C’est la représentation des informations liées spécifiquement au
domaine de l’application.
C’est un autre nom pour désigner la couche métier.
La couche métier ou plutôt la partie qui représente l’information
en respectant une structure liée au domaine d’activité, celle qui
effectue des calculs ou des traitements amenant une plus value
sur l’information brute.
Par exemple le calcul du total des taxes sur un prix hors taxe ou
encore des vérifications telles que : Y a t-il encore des articles en
stock avant d’autoriser une sortie de stock.
Claude Duvallet — 36/42 Framework
Introduction
Les services et les modules
Les patrons de conception
Le modèle MVC 1 et 2 (Model View Controller) (4/9)
La vue (View) :
Cette couche ou ce module effectue le rendu de la couche métier
dans une forme qui est compréhensible par l’homme, par
exemple une page html.
Attention souvent le concept MVC est associé à une application
web mais ce n’est pas obligatoire : en effet le framework Swing
qui permet de produire des interfaces utilisateurs "sous forme de
clients lourds" permet également d’implémenter MVC.
Le contrôleur (Controller) :
Ce module organise la communication entre les deux premiers.
Il invoquera une action dans la couche métier (par exemple
récupérer les données d’un client) suite à une action de
l’utilisateur et passera cette information à la vue (jsp qui affiche
les détails).
Claude Duvallet — 37/42 Framework
Introduction
Les services et les modules
Les patrons de conception
Le modèle MVC 1 et 2 (Model View Controller) (5/9)
La couche d’accès aux données est ignorée ici parce que sous
jacente à la couche métier.
Tout d’abord cela vous permettra de pouvoir debugger et tester
plus facilement le code en l’isolant de la partie affichage.
En effet, la plupart des bugs sont des problèmes avec l’interface
donc ce n’est pas la peine de compliquer encore la donne avec
des bugs métiers ou d’accès aux données.
De plus, le jour où il vous faudra rendre l’application compatible
avec les téléphones portables vous n’aurez qu’à remplacer la
partie Vue par une vue qui supporte wml par exemple.
Claude Duvallet — 38/42 Framework
Introduction
Les services et les modules
Les patrons de conception
Le modèle MVC 1 et 2 (Model View Controller) (6/9)
Le modèle MVC version 1 :
Claude Duvallet — 39/42 Framework
Introduction
Les services et les modules
Les patrons de conception
Le modèle MVC 1 et 2 (Model View Controller) (7/9)
Le problème de ce design pattern est la partie concernant les
notifications de changement dans le modèle.
En effet, si ce point ne pose pas de problème dans le cadre de
swing par exemple, où les composants de la vue sont connectés
et capables d’intelligence, il n’en est pas de même pour les
applications web.
Dans le cadre d’une application web, c’est le design pattern
MVC2 qui est utilisé car il ne nécessite pas l’emploi du design
pattern observer.
Ce dernier permet la notification sur les composants : il observe
le modèle et permet à la vue de réagir pour se mettre à jour.
Claude Duvallet — 40/42 Framework
Introduction
Les services et les modules
Les patrons de conception
Le modèle MVC 1 et 2 (Model View Controller) (8/9)
Le modèle MVC version 2 :
Claude Duvallet — 41/42 Framework
Introduction
Les services et les modules
Les patrons de conception
Le modèle MVC 1 et 2 (Model View Controller) (9/9)
On remarque que c’est le contrôleur qui devient le module central.
De fait, la vue peut à présent se contenter d’afficher sans aucune
intelligence.
Cependant, même si le design MVC permet de mieux séparer les
couches, il ne faut pas oublier qu’il ne s’agit pas de la façon de
procéder la plus intuitive.
Elle induit donc d’investir du temps dans la réflexion sur la façon
de séparer les différentes couches et technologies et surtout de
bien réfléchir dans quelle couche s’effectue quel traitement.
De plus les frameworks génèrent souvent plus de fichiers et
naturellement plus de configuration.
Ce surplus de complexité est cependant bien contrebalancé par
la flexibilité supérieure, la plus grande fiabilité, une plus grande
facilité pour tester et débugger (puisque que l’on peut tester les
bouts un à un).
Claude Duvallet — 42/42 Framework
1 de 42

Recomendados

Design Patterns Java por
Design Patterns JavaDesign Patterns Java
Design Patterns JavaVINOT Bernard
7.2K visualizações239 slides
Mohamed youssfi support architectures logicielles distribuées basées sue les ... por
Mohamed youssfi support architectures logicielles distribuées basées sue les ...Mohamed youssfi support architectures logicielles distribuées basées sue les ...
Mohamed youssfi support architectures logicielles distribuées basées sue les ...ENSET, Université Hassan II Casablanca
105.7K visualizações122 slides
Design patterns por
Design patternsDesign patterns
Design patternsEric Toguem
3K visualizações60 slides
Support JEE Spring Inversion de Controle IOC et Spring MVC por
Support JEE Spring Inversion de Controle IOC et Spring MVCSupport JEE Spring Inversion de Controle IOC et Spring MVC
Support JEE Spring Inversion de Controle IOC et Spring MVCENSET, Université Hassan II Casablanca
38K visualizações122 slides
Programmation orientee aspect 201401 - Ensim por
Programmation orientee aspect 201401 - EnsimProgrammation orientee aspect 201401 - Ensim
Programmation orientee aspect 201401 - EnsimLaurent Broudoux
1.6K visualizações48 slides
Programmation orienté aspect por
Programmation orienté aspectProgrammation orienté aspect
Programmation orienté aspectmeriem sari
914 visualizações16 slides

Mais conteúdo relacionado

Mais procurados

Design patterns - Exemples en Java por
Design patterns - Exemples en JavaDesign patterns - Exemples en Java
Design patterns - Exemples en JavaOussama BEN KHIROUN
3.7K visualizações25 slides
Abstract factory+adapter por
Abstract factory+adapterAbstract factory+adapter
Abstract factory+adapterKamel Eddine Heragmi
1.2K visualizações17 slides
Spring Meetup Paris - Back to the basics of Spring (Boot) por
Spring Meetup Paris - Back to the basics of Spring (Boot)Spring Meetup Paris - Back to the basics of Spring (Boot)
Spring Meetup Paris - Back to the basics of Spring (Boot)Eric SIBER
4.3K visualizações109 slides
Cours de Génie Logiciel / ESIEA 2013-2014 por
Cours de Génie Logiciel / ESIEA 2013-2014 Cours de Génie Logiciel / ESIEA 2013-2014
Cours de Génie Logiciel / ESIEA 2013-2014 Thierry Leriche-Dessirier
6.5K visualizações221 slides
Patterns Windows Azure por
Patterns Windows AzurePatterns Windows Azure
Patterns Windows AzureMicrosoft
732 visualizações59 slides
Java entreprise edition et industrialisation du génie logiciel par m.youssfi por
Java entreprise edition et industrialisation du génie logiciel par m.youssfiJava entreprise edition et industrialisation du génie logiciel par m.youssfi
Java entreprise edition et industrialisation du génie logiciel par m.youssfiENSET, Université Hassan II Casablanca
24.4K visualizações416 slides

Mais procurados(20)

Design patterns - Exemples en Java por Oussama BEN KHIROUN
Design patterns - Exemples en JavaDesign patterns - Exemples en Java
Design patterns - Exemples en Java
Oussama BEN KHIROUN3.7K visualizações
Abstract factory+adapter por Kamel Eddine Heragmi
Abstract factory+adapterAbstract factory+adapter
Abstract factory+adapter
Kamel Eddine Heragmi1.2K visualizações
Spring Meetup Paris - Back to the basics of Spring (Boot) por Eric SIBER
Spring Meetup Paris - Back to the basics of Spring (Boot)Spring Meetup Paris - Back to the basics of Spring (Boot)
Spring Meetup Paris - Back to the basics of Spring (Boot)
Eric SIBER4.3K visualizações
Cours de Génie Logiciel / ESIEA 2013-2014 por Thierry Leriche-Dessirier
Cours de Génie Logiciel / ESIEA 2013-2014 Cours de Génie Logiciel / ESIEA 2013-2014
Cours de Génie Logiciel / ESIEA 2013-2014
Thierry Leriche-Dessirier6.5K visualizações
Patterns Windows Azure por Microsoft
Patterns Windows AzurePatterns Windows Azure
Patterns Windows Azure
Microsoft732 visualizações
patron de conception por Shili Mohamed
patron de conception patron de conception
patron de conception
Shili Mohamed4.3K visualizações
Telosys tools jug-nantes-2014-v1.2 por Laurent Guérin
Telosys tools jug-nantes-2014-v1.2Telosys tools jug-nantes-2014-v1.2
Telosys tools jug-nantes-2014-v1.2
Laurent Guérin2K visualizações
Design patterns : résumé por Boubker ABERWAG
Design patterns : résuméDesign patterns : résumé
Design patterns : résumé
Boubker ABERWAG3.5K visualizações
Design patterns french por meriem sari
Design patterns frenchDesign patterns french
Design patterns french
meriem sari1.1K visualizações
Introduction aux problématiques des architectures distribuées por SOAT
Introduction aux problématiques des architectures distribuéesIntroduction aux problématiques des architectures distribuées
Introduction aux problématiques des architectures distribuées
SOAT973 visualizações
Spring & SpringBatch FR por Marouan MOHAMED
Spring & SpringBatch FRSpring & SpringBatch FR
Spring & SpringBatch FR
Marouan MOHAMED1.2K visualizações
Aspect avec AspectJ por simeon
Aspect avec AspectJAspect avec AspectJ
Aspect avec AspectJ
simeon2.2K visualizações

Similar a Cours spring

Etude des Frameworks PHP por
Etude des Frameworks PHPEtude des Frameworks PHP
Etude des Frameworks PHPJEAN-GUILLAUME DUJARDIN
1.6K visualizações18 slides
Modele mvc por
Modele mvcModele mvc
Modele mvcSoulef riahi
1.7K visualizações16 slides
2 ModéLe Mvc por
2 ModéLe Mvc2 ModéLe Mvc
2 ModéLe MvcDghaies Jihed , PSM I Ⓡ
9.4K visualizações11 slides
Spring por
SpringSpring
SpringDghaies Jihed , PSM I Ⓡ
3.2K visualizações17 slides
At2008 Grenoble Hugonnet Sanlaville Public por
At2008 Grenoble Hugonnet Sanlaville PublicAt2008 Grenoble Hugonnet Sanlaville Public
At2008 Grenoble Hugonnet Sanlaville PublicEmmanuel Hugonnet
1.6K visualizações58 slides

Similar a Cours spring(20)

Modele mvc por Soulef riahi
Modele mvcModele mvc
Modele mvc
Soulef riahi1.7K visualizações
At2008 Grenoble Hugonnet Sanlaville Public por Emmanuel Hugonnet
At2008 Grenoble Hugonnet Sanlaville PublicAt2008 Grenoble Hugonnet Sanlaville Public
At2008 Grenoble Hugonnet Sanlaville Public
Emmanuel Hugonnet1.6K visualizações
Workshop Spring - Session 1 - L'offre Spring et les bases por Antoine Rey
Workshop Spring  - Session 1 - L'offre Spring et les basesWorkshop Spring  - Session 1 - L'offre Spring et les bases
Workshop Spring - Session 1 - L'offre Spring et les bases
Antoine Rey8.6K visualizações
Presentation Spring por Nathaniel Richand
Presentation SpringPresentation Spring
Presentation Spring
Nathaniel Richand7.6K visualizações
Design applicatif avec symfony2 por RomainKuzniak
Design applicatif avec symfony2Design applicatif avec symfony2
Design applicatif avec symfony2
RomainKuzniak9.5K visualizações
Common features in webapi aspnetcore por MSDEVMTL
Common features in webapi aspnetcoreCommon features in webapi aspnetcore
Common features in webapi aspnetcore
MSDEVMTL107 visualizações
Entity_framework_db first por Zineb ELGARRAI
Entity_framework_db firstEntity_framework_db first
Entity_framework_db first
Zineb ELGARRAI272 visualizações
Outils de construction pour la recherche por Johan Moreau
Outils de construction pour la rechercheOutils de construction pour la recherche
Outils de construction pour la recherche
Johan Moreau573 visualizações
Presentation du socle technique Java open source Scub Foundation por Stéphane Traumat
Presentation du socle technique Java open source Scub FoundationPresentation du socle technique Java open source Scub Foundation
Presentation du socle technique Java open source Scub Foundation
Stéphane Traumat3.5K visualizações
Sonar-Hodson-Maven por Slimen Belhaj Ali
Sonar-Hodson-MavenSonar-Hodson-Maven
Sonar-Hodson-Maven
Slimen Belhaj Ali2.3K visualizações
Serveur node red por FerchichiYassine
Serveur node redServeur node red
Serveur node red
FerchichiYassine112 visualizações
Plateforme De DéVeloppement En Php5 (Zend + Doctrine) por cornnery
Plateforme De DéVeloppement En Php5 (Zend + Doctrine)Plateforme De DéVeloppement En Php5 (Zend + Doctrine)
Plateforme De DéVeloppement En Php5 (Zend + Doctrine)
cornnery3.6K visualizações
Rex Software Factories 20140117 - Ensim por Laurent Broudoux
Rex Software Factories 20140117 - EnsimRex Software Factories 20140117 - Ensim
Rex Software Factories 20140117 - Ensim
Laurent Broudoux1.4K visualizações
Livre blanc a la decouverte de windows azure por Microsoft Technet France
Livre blanc a la decouverte de windows azureLivre blanc a la decouverte de windows azure
Livre blanc a la decouverte de windows azure
Microsoft Technet France695 visualizações
Créer une application web en asp.net mvc 2 por Novencia Groupe
Créer une application web en asp.net mvc 2Créer une application web en asp.net mvc 2
Créer une application web en asp.net mvc 2
Novencia Groupe3.7K visualizações

Último

Caprinov2023 Réussite à l’IA des chèvres : effet de la diversité des trajecto... por
Caprinov2023 Réussite à l’IA des chèvres : effet de la diversité des trajecto...Caprinov2023 Réussite à l’IA des chèvres : effet de la diversité des trajecto...
Caprinov2023 Réussite à l’IA des chèvres : effet de la diversité des trajecto...Institut de l'Elevage - Idele
61 visualizações20 slides
GAV2023 - L’albédo (α) des prairies : un levier d'atténuation du changement c... por
GAV2023 - L’albédo (α) des prairies : un levier d'atténuation du changement c...GAV2023 - L’albédo (α) des prairies : un levier d'atténuation du changement c...
GAV2023 - L’albédo (α) des prairies : un levier d'atténuation du changement c...Institut de l'Elevage - Idele
127 visualizações18 slides
Caprinov2023 2023, une amélioration de la situation, des prix de vente à prés... por
Caprinov2023 2023, une amélioration de la situation, des prix de vente à prés...Caprinov2023 2023, une amélioration de la situation, des prix de vente à prés...
Caprinov2023 2023, une amélioration de la situation, des prix de vente à prés...Institut de l'Elevage - Idele
33 visualizações32 slides
GAV2023 - La filière bovins viande face aux imports - Point sur les accords d... por
GAV2023 - La filière bovins viande face aux imports - Point sur les accords d...GAV2023 - La filière bovins viande face aux imports - Point sur les accords d...
GAV2023 - La filière bovins viande face aux imports - Point sur les accords d...Institut de l'Elevage - Idele
159 visualizações16 slides
GAV2023 - Les systèmes bovins viande à l'épreuve des défis : les dynamiques d... por
GAV2023 - Les systèmes bovins viande à l'épreuve des défis : les dynamiques d...GAV2023 - Les systèmes bovins viande à l'épreuve des défis : les dynamiques d...
GAV2023 - Les systèmes bovins viande à l'épreuve des défis : les dynamiques d...Institut de l'Elevage - Idele
146 visualizações23 slides
GAV2023 - Un outil pour centraliser les auto-contrôles des abattoirs et ateli... por
GAV2023 - Un outil pour centraliser les auto-contrôles des abattoirs et ateli...GAV2023 - Un outil pour centraliser les auto-contrôles des abattoirs et ateli...
GAV2023 - Un outil pour centraliser les auto-contrôles des abattoirs et ateli...Institut de l'Elevage - Idele
118 visualizações14 slides

Último(20)

Caprinov2023 Réussite à l’IA des chèvres : effet de la diversité des trajecto... por Institut de l'Elevage - Idele
Caprinov2023 Réussite à l’IA des chèvres : effet de la diversité des trajecto...Caprinov2023 Réussite à l’IA des chèvres : effet de la diversité des trajecto...
Caprinov2023 Réussite à l’IA des chèvres : effet de la diversité des trajecto...
Institut de l'Elevage - Idele61 visualizações
GAV2023 - L’albédo (α) des prairies : un levier d'atténuation du changement c... por Institut de l'Elevage - Idele
GAV2023 - L’albédo (α) des prairies : un levier d'atténuation du changement c...GAV2023 - L’albédo (α) des prairies : un levier d'atténuation du changement c...
GAV2023 - L’albédo (α) des prairies : un levier d'atténuation du changement c...
Institut de l'Elevage - Idele127 visualizações
Caprinov2023 2023, une amélioration de la situation, des prix de vente à prés... por Institut de l'Elevage - Idele
Caprinov2023 2023, une amélioration de la situation, des prix de vente à prés...Caprinov2023 2023, une amélioration de la situation, des prix de vente à prés...
Caprinov2023 2023, une amélioration de la situation, des prix de vente à prés...
Institut de l'Elevage - Idele33 visualizações
GAV2023 - La filière bovins viande face aux imports - Point sur les accords d... por Institut de l'Elevage - Idele
GAV2023 - La filière bovins viande face aux imports - Point sur les accords d...GAV2023 - La filière bovins viande face aux imports - Point sur les accords d...
GAV2023 - La filière bovins viande face aux imports - Point sur les accords d...
Institut de l'Elevage - Idele159 visualizações
GAV2023 - Les systèmes bovins viande à l'épreuve des défis : les dynamiques d... por Institut de l'Elevage - Idele
GAV2023 - Les systèmes bovins viande à l'épreuve des défis : les dynamiques d...GAV2023 - Les systèmes bovins viande à l'épreuve des défis : les dynamiques d...
GAV2023 - Les systèmes bovins viande à l'épreuve des défis : les dynamiques d...
Institut de l'Elevage - Idele146 visualizações
GAV2023 - Un outil pour centraliser les auto-contrôles des abattoirs et ateli... por Institut de l'Elevage - Idele
GAV2023 - Un outil pour centraliser les auto-contrôles des abattoirs et ateli...GAV2023 - Un outil pour centraliser les auto-contrôles des abattoirs et ateli...
GAV2023 - Un outil pour centraliser les auto-contrôles des abattoirs et ateli...
Institut de l'Elevage - Idele118 visualizações
GAV2023 - Evaluer pour gérer le bien-être en élevage bovin viande : outils di... por Institut de l'Elevage - Idele
GAV2023 - Evaluer pour gérer le bien-être en élevage bovin viande : outils di...GAV2023 - Evaluer pour gérer le bien-être en élevage bovin viande : outils di...
GAV2023 - Evaluer pour gérer le bien-être en élevage bovin viande : outils di...
Institut de l'Elevage - Idele125 visualizações
Caprinov2023 Réussite à l’IA des chèvres : effet de la diversité des trajecto... por Institut de l'Elevage - Idele
Caprinov2023 Réussite à l’IA des chèvres : effet de la diversité des trajecto...Caprinov2023 Réussite à l’IA des chèvres : effet de la diversité des trajecto...
Caprinov2023 Réussite à l’IA des chèvres : effet de la diversité des trajecto...
Institut de l'Elevage - Idele63 visualizações
Caprinov2023 Distribution quotidienne des fourrages quelles stratégies pour ... por Institut de l'Elevage - Idele
Caprinov2023 Distribution quotidienne des fourrages  quelles stratégies pour ...Caprinov2023 Distribution quotidienne des fourrages  quelles stratégies pour ...
Caprinov2023 Distribution quotidienne des fourrages quelles stratégies pour ...
Institut de l'Elevage - Idele21 visualizações
GAV2023 - Entre inflation et décapitalisation, une conjoncture mouvementée por Institut de l'Elevage - Idele
GAV2023 - Entre inflation et décapitalisation, une conjoncture mouvementéeGAV2023 - Entre inflation et décapitalisation, une conjoncture mouvementée
GAV2023 - Entre inflation et décapitalisation, une conjoncture mouvementée
Institut de l'Elevage - Idele325 visualizações
GAV2023 - Quel cheptel et quels leviers de décarbonation la filière met en pl... por Institut de l'Elevage - Idele
GAV2023 - Quel cheptel et quels leviers de décarbonation la filière met en pl...GAV2023 - Quel cheptel et quels leviers de décarbonation la filière met en pl...
GAV2023 - Quel cheptel et quels leviers de décarbonation la filière met en pl...
Institut de l'Elevage - Idele157 visualizações
GAV2023 - Quelles perspectives de production de viandes bovines selon les dyn... por Institut de l'Elevage - Idele
GAV2023 - Quelles perspectives de production de viandes bovines selon les dyn...GAV2023 - Quelles perspectives de production de viandes bovines selon les dyn...
GAV2023 - Quelles perspectives de production de viandes bovines selon les dyn...
Institut de l'Elevage - Idele162 visualizações
NOTES MECANIQUE SSAID MEHDI.pptx por mohamedsaid315568
NOTES MECANIQUE SSAID MEHDI.pptxNOTES MECANIQUE SSAID MEHDI.pptx
NOTES MECANIQUE SSAID MEHDI.pptx
mohamedsaid3155685 visualizações
Cours Unix Emsi 2023 2024.pdf por ADNANEELBOUAAMRI
Cours Unix Emsi 2023 2024.pdfCours Unix Emsi 2023 2024.pdf
Cours Unix Emsi 2023 2024.pdf
ADNANEELBOUAAMRI19 visualizações
Caprinov2023 Reconquête de l’engraissement du chevreau à la ferme comment en... por Institut de l'Elevage - Idele
Caprinov2023 Reconquête de l’engraissement du chevreau à la ferme  comment en...Caprinov2023 Reconquête de l’engraissement du chevreau à la ferme  comment en...
Caprinov2023 Reconquête de l’engraissement du chevreau à la ferme comment en...
Institut de l'Elevage - Idele36 visualizações
GAV2023 - Diversité et transformation de l'élevage bovin allaitant français. ... por Institut de l'Elevage - Idele
GAV2023 - Diversité et transformation de l'élevage bovin allaitant français. ...GAV2023 - Diversité et transformation de l'élevage bovin allaitant français. ...
GAV2023 - Diversité et transformation de l'élevage bovin allaitant français. ...
Institut de l'Elevage - Idele182 visualizações
GAV2023 - Méthane 2030 - Une démarche collective française à destination de t... por Institut de l'Elevage - Idele
GAV2023 - Méthane 2030 - Une démarche collective française à destination de t...GAV2023 - Méthane 2030 - Une démarche collective française à destination de t...
GAV2023 - Méthane 2030 - Une démarche collective française à destination de t...
Institut de l'Elevage - Idele149 visualizações
BeBop : l’apport des vidéos pour analyser le comportement des taurillons por Institut de l'Elevage - Idele
BeBop : l’apport des vidéos pour analyser le comportement des taurillonsBeBop : l’apport des vidéos pour analyser le comportement des taurillons
BeBop : l’apport des vidéos pour analyser le comportement des taurillons
Institut de l'Elevage - Idele14 visualizações
Caprinov2023 Un nouveau guide pour l’élevage des chevrettes, un nouvel outil ... por Institut de l'Elevage - Idele
Caprinov2023 Un nouveau guide pour l’élevage des chevrettes, un nouvel outil ...Caprinov2023 Un nouveau guide pour l’élevage des chevrettes, un nouvel outil ...
Caprinov2023 Un nouveau guide pour l’élevage des chevrettes, un nouvel outil ...
Institut de l'Elevage - Idele32 visualizações

Cours spring

  • 1. Introduction Les services et les modules Les patrons de conception Les Framework Java Spring Claude Duvallet Université du Havre UFR Sciences et Techniques 25 rue Philippe Lebon - BP 540 76058 LE HAVRE CEDEX Claude.Duvallet@gmail.com http://litis.univ-lehavre.fr/∼duvallet/ Claude Duvallet — 1/42 Framework
  • 2. Introduction Les services et les modules Les patrons de conception Spring 1 Introduction 2 Les services et les modules 3 Les patrons de conception Claude Duvallet — 2/42 Framework
  • 3. Introduction Les services et les modules Les patrons de conception Présentation de Spring (1/2) SPRING est effectivement un conteneur dit « léger », c’est-à-dire une infrastructure similaire à un serveur d’application J2EE. Il prend en charge la création d’objets et la mise en relation d’objets par l’intermédiaire d’un fichier de configuration qui décrit les objets à fabriquer et les relations de dépendances entre ces objets. Le gros avantage par rapport aux serveurs d’application est qu’avec SPRING, vos classes n’ont pas besoin d’implémenter une quelconque interface pour être prises en charge par le framework (au contraire des serveurs d’applications J2EE et des EJBs). C’est en ce sens que SPRING est qualifié de conteneur « léger ». Claude Duvallet — 3/42 Framework
  • 4. Introduction Les services et les modules Les patrons de conception Présentation de Spring (2/2) Outre cette espèce de super fabrique d’objets, SPRING propose tout un ensemble d’abstractions permettant de gérer entre autres : Le mode transactionnel. L’appel d’EJBs. La création d’EJBs. La persistance d’objets La création d’une interface Web. L’appel et la création de WebServices. Pour réaliser tout ceci, SPRING s’appuie sur les principes du design pattern IoC et sur la programmation par aspects (AOP). Spring est disponible sous licence Apache 2.0. Claude Duvallet — 4/42 Framework
  • 5. Introduction Les services et les modules Les patrons de conception Les services fournis par Spring (1/2) Spring propose les services suivants (liste non-exhaustive) : Découplage des composants. Moins d’interdépendances entre les différents modules. Rendre plus aisés les tests des applications complexes c’est-à-dire des applications multicouches. Diminuer la quantité de code par l’intégration de frameworks tiers directement dans Spring. Permettre de mettre en oeuvre facilement la programmation orientée aspect. Un système de transactions au niveau métier qui permet par exemple de faire du "two-phases-commit". Claude Duvallet — 5/42 Framework
  • 6. Introduction Les services et les modules Les patrons de conception Les services fournis par Spring (2/2) Un mécanisme de sécurité. Pas de dépendances dans le code à l’api Spring lors l’utilisation de l’injection. Ce qui permet de remplacer une couche sans impacter les autres. Une implémentation du design pattern MVC Un support du protocole RMI. Tant au niveau serveur qu’au niveau du client. Déployer et consommer des web-services très facilement. Echanger des objets par le protocole http. Claude Duvallet — 6/42 Framework
  • 7. Introduction Les services et les modules Les patrons de conception Les modules de Spring (1/2) Le framework est organisé en modules, reposant tous sur le module Spring Core : Spring Core : implémente notamment le concept d’inversion de contrôle (injection de dépendance). Il est également responsable de la gestion et de la configuration du conteneur. Spring Context : Ce module étend Spring Core. Il fournit une sorte de base de données d’objets, permet de charger des ressources (telles que des fichiers de configuration) ou encore la propagation d’évènements et la création de contexte comme par exemple le support de Spring dans un conteneur de Servlet. Spring AOP : Permet d’intégrer de la programmation orientée aspect. Spring DAO : Ce module permet d’abstraire les accès à la base de données, d’éliminer le code redondant et également d’abstraire les messages d’erreur spécifiques à chaque vendeur. Il fournit en outre une gestion des transactions. Claude Duvallet — 7/42 Framework
  • 8. Introduction Les services et les modules Les patrons de conception Les modules de Spring (2/2) Spring ORM : Cette partie permet d’intégrer des frameworks de mapping Object/Relationnel tel que Hibernate, JDO ou iBatis avec Spring. La quantité de code économisé par ce package peut être très impressionnante (ouverture, fermeture de session, gestion des erreurs) Spring Web : Ensemble d’utilitaires pour les applications web. Par exemple une servlet qui démarre le contexte (le conteneur) au démarrage d’une application web. Permet également d’utiliser des requêtes http de type multipart. C’est aussi ici que se fait l’intégration avec le framework Struts. Spring Web MVC : Implémentation du modèle MVC. Personnellement j’utilise plutôt Struts mais c’est surtout une question d’habitude, c’est là la grande force de Spring, rien ne vous oblige à tout utiliser et vous pouvez tout mélanger. Ce qui n’est pas forcément une bonne idée mais nous en reparlerons. Claude Duvallet — 8/42 Framework
  • 9. Introduction Les services et les modules Les patrons de conception Les patrons de conception En anglais, on parle de Design Pattern. Spring repose sur des concepts éprouvés, patrons de conception et paradigmes, dont les plus connus sont IoC (Inversion of Control), le singleton, la programmation orientée Aspect, ou encore le modèle de programmation dit "par template". Ces concepts n’étant pas propre à Spring, ils s’appliquent également à d’autres frameworks. Claude Duvallet — 9/42 Framework
  • 10. Introduction Les services et les modules Les patrons de conception Le modèle de conception "fabrique" (factory) (1/3) C’est grâce à ce modèle que Spring peut produire des objets respectant un contrat mais indépendants de leur implémentation. En réalité, ce modèle est basé sur la notion d’interface et donc de contrat. L’idée est simplement d’avoir un point d’entrée unique qui permet de produire des instances d’objets. Tout comme une usine produit plusieurs types de voitures, cette usine a comme caractéristique principale de produire des voitures De la même façon une fabrique d’objets produira n’importe quel type d’objet pour peu qu’ils respectent le postulat de base. Ce postulat (le contrat) pouvant être très vague ou au contraire très précis. Claude Duvallet — 10/42 Framework
  • 11. Introduction Les services et les modules Les patrons de conception Le modèle de conception "fabrique" (factory) (2/3) Voyons le diagramme de classe : On remarque facilement que le simple fait de changer la méthode getForm() permet de passer d’un formulaire de type swing à un formulaire de type html. Cela sans avoir le moindre impact sur tout le code qui en découle. Claude Duvallet — 11/42 Framework
  • 12. Introduction Les services et les modules Les patrons de conception Le modèle de conception "fabrique" (factory) (3/3) Nous avons vu ci-dessus que Spring encourageait la programmation par contrat en voici l’une des nombreuses raisons. Bien entendu aussi longtemps que le programmeur chargé de réaliser la classe SwingForm n’aura pas terminé sa tâche, la méthode getForm() pourra renvoyer une instance d’une pseudo implémentation qui renvoie toujours null ou certaines erreurs remplies en dur pour pouvoir tester et développer les classes clientes. Naturellement à lui seul ce pattern ne suffit pas, il faudra lui adjoindre le singleton et des possibilités de configuration ainsi que le modèle "bean". Dès lors le pattern IoC (Inversion of control) sera réalisable. Claude Duvallet — 12/42 Framework
  • 13. Introduction Les services et les modules Les patrons de conception Le singleton (1/2) Il s’agit certainement du patron de conception le plus connu. En effet, il est (très) utilisé dans beaucoup de domaines. Ce modèle revient à s’assurer qu’il n’y aura toujours qu’une instance d’une classe donnée qui sera instanciée dans la machine virtuelle. Les objectifs sont simples : 1 Eviter le temps d’instanciation de la classe. 2 Eviter la consommation de mémoire inutile. Ce modèle impose cependant une contrainte d’importance, la classe qui fournit le service ne doit pas avoir de notion de session. Claude Duvallet — 13/42 Framework
  • 14. Introduction Les services et les modules Les patrons de conception Le singleton (2/2) C’est à dire qu’importe le module appelant, le service réagira toujours de la même façon à paramètre équivalent, il n’a pas de notion d’historique (ou de session). Le POJO qui implémentera le service ne doit pas stocker des informations au niveau de l’objet lui-même. Pour faire simple il ne faut pas modifier les variables membres au sein d’une opération (une méthode du service). Ce concept relativement simple à appréhender, est également simple à mettre en oeuvre. Du moins en théorie. L’objectif est de garantir l’unicité de l’instance, pour cela il faut interdire la création de toute instance en dehors du contrôle de la classe. Dans ce but, le constructeur est rendu privé et une méthode qui retourne une instance de la classe est mise à disposition. Claude Duvallet — 14/42 Framework
  • 15. Introduction Les services et les modules Les patrons de conception Le diagramme de classe du Singleton (1/2) Ce diagramme de classe se traduit par la portion de code suivante : public class Singleton { public static Singleton getInstance() { if (instance == null) { instance = new Singleton(); } return instance; } private Singleton() {} private static Singleton instance; } Claude Duvallet — 15/42 Framework
  • 16. Introduction Les services et les modules Les patrons de conception Le diagramme de classe du Singleton (2/2) En fait il manque quelque chose pour que ce soit une implémentation correcte du singleton. Il s’agit du problème du multithreading, en effet si plusieurs threads accèdent de façon simultanée à la méthode getInstance() il se peut que les deux threads détectent en même temps que le membre est null ce qui conduira à un problème. Pour cela, il faudrait déclarer la méthode synchronized ou tout du moins la portion de code qui manipule l’instance. C’est justement un des avantages de Spring, vous n’avez plus à vous soucier de cela, Spring le fait et il le fait très bien. Claude Duvallet — 16/42 Framework
  • 17. Introduction Les services et les modules Les patrons de conception L’inversion de contrôle (1/5) L’inversion de contrôle (IoC : Inversion of Control) ou l’injection de dépendances (Dependency Injection) est sans doute le concept central de Spring. Il s’agit d’un "design pattern" qui a pour objectif de faciliter l’intégration de composants entre eux. Le concept est basé sur le fait d’inverser la façon dont sont créés les objets. Dans la plupart des cas, si je souhaite créer un objet qui en utilise un autre je programmerai quelque chose du type : DBConnexion c=new DBConnexion("jdbc:... ") ; Pool p=new Pool(c); //reste du code SecurityDAO securityDao=new SecurityDao(p); SecurityBusiness securityBusiness=new securityBusiness(securityDao); Claude Duvallet — 17/42 Framework
  • 18. Introduction Les services et les modules Les patrons de conception L’inversion de contrôle (2/5) À présent votre chef de projet, vous dit : "le client a changé d’avis, il souhaite utiliser LDAP et non sa base de données pour l’identification". Donc, vous devez changer en : Properties p=new Properties ("ldap.properties"); LDAPConnexion c=new LDAPConnexion(p) ; //reste du code SecurityDAO securityDao=new SecurityDao(c); SecurityBusiness securityBusiness=new securityBusiness(securityDao); De là, votre chef de projet revient, et vous dit que la direction a décidé d’en faire un produit standard compatible avec toutes les bases de données et systèmes d’authentification comme Active Directory. Bon, à présent pour vous ça devient moins drôle. La solution consiste à bien séparer les couches et à utiliser des interfaces pour se faire. Claude Duvallet — 18/42 Framework
  • 19. Introduction Les services et les modules Les patrons de conception L’inversion de contrôle (3/5) Naturellement, il ne s’agit pas de quelque chose de propre à Spring, donc dans un premier temps nous aurons : IConnexion c=new LDAPConnexionImpl () ; ISecurityDAO securityDao=new LDAPSecurityDaoImpl(c); ISecurityBusiness securityBusiness=new SecurityBusinessImpl(securityDao); Maintenant le problème qui se pose est celui de la configuration, comment configurer de manière simple les drivers et les objets nécessaires. Et surtout comment faire pour que le tout s’intègre proprement dans l’application. ⇒ Entrée en jeu de l’inversion de contrôle. L’objectif n’est plus de fournir un objet à un autre objet mais au contraire de faire en sorte que, l’objet dont on a besoin, sache lui-même ce dont il a besoin. Et le cas échéant si un des objets nécessaires a lui-même des dépendances qu’il se débrouille pour les obtenir. Claude Duvallet — 19/42 Framework
  • 20. Introduction Les services et les modules Les patrons de conception L’inversion de contrôle (4/5) Ce qui devrait résulter en : ISecurityBusiness securityBusiness=IoCContainer.getBean("ISecurityBean); La méthode getBean est purement formelle pour l’exemple, l’objectif est de montrer que le code est réduit à sa forme la plus simple, les dépendances étant déclarées dans la configuration du conteneur. Le rôle de cette méthode : 1 Elle résout le nom ISecurityBean dans son arbre de dépendances et trouve la classe qui l’implémente. 2 Elle en crée une instance (cas d’une injection pas mutateurs). 3 Elle crée les objets dépendants et les définit dans l’objet ISecurityBean grâce à ses accesseurs. 4 Et enfin, récursivement elle fait de même pour toutes les dépendances des dépendances. Claude Duvallet — 20/42 Framework
  • 21. Introduction Les services et les modules Les patrons de conception L’inversion de contrôle (5/5) Sur la figure suivante on remarque que les dépendances entre les couches sont réduites au minimum et que l’on peut facilement remplacer une implémentation par une autre sans mettre en danger la stabilité et l’intégrité de l’ensemble. Claude Duvallet — 21/42 Framework
  • 22. Introduction Les services et les modules Les patrons de conception La notion d’injection de dépendances Il existe trois types d’injection : L’injection par constructeurs. L’injection par mutateurs (setters). L’injection d’interface. Claude Duvallet — 22/42 Framework
  • 23. Introduction Les services et les modules Les patrons de conception L’injection par constructeurs Ce type d’injection se fait sur le constructeur, c’est-à-dire que le constructeur dispose de paramètres pour directement initialiser tous les membres de la classe. Object construitComposant(String pNom){ Class c=rechercheLaClassQuiImplemente(pNom) ; String[] dep= rechercheLesDependance(pNom) ; Params[] parametresDeConstructeur; Pour chaque element (composant) de dep Faire Object o= construitComposant(composant) ; Rajouter o à la liste de parametresDeConstructeur ; Fin Faire construireClasse( c, parametresDeConstructeur) } Claude Duvallet — 23/42 Framework
  • 24. Introduction Les services et les modules Les patrons de conception L’injection par mutateurs (setters) Ce type d’injection se fait après une initialisation à l’aide d’un constructeur sans paramètre puis les différents champs sont initialisés grâce à des mutateurs. composant.setNomMembre(o) : le nom setNomMembre est trouvé grâce à la configuration du composant où il est déclaré : le membre à initialiser est nomMembre. Object construitComposant(String pNom){ Class c=rechercheLaClassQuiImplemente(pNom) ; Object composanr=new c() ; String[] dep= rechercheLesDependance(pNom) ; Params[] parametresDeConstructeur; Pour chaque element (composant) de dep Faire Object o= construitComposant(composant) ; composant.setNomMembre(o) ; Fin Faire } Claude Duvallet — 24/42 Framework
  • 25. Introduction Les services et les modules Les patrons de conception L’injection d’interface (1/2) Cette injection se fait sur la base d’une méthode. Elle est proche de l’injection par mutateurs, la différence se résume à pouvoir utiliser un autre nom de méthode que ceux du "design pattern bean". Pour cela, il faut utiliser une interface afin de définir le nom de la méthode qui injectera la dépendance. Object construitComposant(String pNom){ Class c=rechercheLaClassQuiImplemente(pNom) ; Object composanr=new c() ; String[] dep= rechercheLesDependance(pNom) ; Params[] parametresDeConstructeur; Pour chaque element (composant) de dep Faire Object o= construitComposant(composant) ; composant.méthodeInjection(o) ; Fin Faire } Claude Duvallet — 25/42 Framework
  • 26. Introduction Les services et les modules Les patrons de conception L’injection d’interface (2/2) composant.méthodeInjection(o) : le nom méthodeInjection est trouvé grâce à la configuration du composant où il est déclaré. La méthode qui injecte l’objet est définie par une interface. Dans notre exemple, l’interface serait : public interface IInjectMethode{ public void méthodeInjection(Object o); } L’implémentation du composant se devra alors d’implémenter cette interface également. Claude Duvallet — 26/42 Framework
  • 27. Introduction Les services et les modules Les patrons de conception Programmation orienté Aspect (1/4) Comme nous pouvons le voir dans la figure suivante, un module ou composant métier est régulièrement pollué par de multiples appels à des composants utilitaires externes. Claude Duvallet — 27/42 Framework
  • 28. Introduction Les services et les modules Les patrons de conception Programmation orienté Aspect (2/4) De fait, ces appels rendent le code plus complexe et donc moins lisible. Comme chacun sait, un code plus court et donc plus clair améliore la qualité et la réutilisabilité. L’utilisation de composants externes implique : 1 Enchevêtrement du code. 2 Faible réutilisabilité. 3 Qualité plus basse due à la complexité du code. 4 Difficulté à faire évoluer. Claude Duvallet — 28/42 Framework
  • 29. Introduction Les services et les modules Les patrons de conception Programmation orienté Aspect (3/4) La solution constituerait donc à externaliser tous les traitements non relatifs à la logique métier en dehors du composant. Pour ce faire il faut pouvoir définir des traitements de façon déclarative ou programmative sur les points clés de l’algorithme. Typiquement avant ou après une méthode. Dans la plupart des cas, ce genre de traitements utilitaires se fait en début ou en fin de méthode, comme par exemple journaliser les appels ou encore effectuer un commit ou un rollback sur une transaction. La démarche est alors la suivante : 1 Décomposition en aspect : Séparer la partie métier de la partie utilitaire. 2 Programmation de la partie métier : Se concentrer sur la partie variante. 3 Recomposition des aspects : Définition des aspects. Claude Duvallet — 29/42 Framework
  • 30. Introduction Les services et les modules Les patrons de conception Programmation orienté Aspect (4/4) Il existe deux types de programmation orientée aspect, ces deux techniques ont chacune des avantages et des inconvénients : l’approche statique, c’est-à-dire que la connexion entre l’aspect et la partie métier se fait au moment de la compilation ou après dans une phase de post-production. Par exemple par manipulation du bytecode. ⇒ Comme toujours cette méthode intrusive n’est pas forcément la plus transparente. L’approche dynamique, dans ce cas, la connexion s’effectue par la réflexion donc au moment de l’exécution. ⇒ Cette méthode bien que plus transparente est naturellement plus lente, mais présente l’avantage de pouvoir être reconfigurée sans recompilation. Claude Duvallet — 30/42 Framework
  • 31. Introduction Les services et les modules Les patrons de conception Programmation par template (1/3) L’objet de ce design pattern est de séparer l’invariant d’un procédé de sa partie variante. Dans Spring les templates sont très utilisés dans le cadre de l’accès aux données et de la gestion des transactions. Claude Duvallet — 31/42 Framework
  • 32. Introduction Les services et les modules Les patrons de conception Programmation par template (2/3) La partie invariante du code est placée dans la partie abstraite de la classe, ainsi toute classe qui héritera de cette classe abstraite n’aura qu’à implémenter la partie variante. Voici un exemple d’utilisation du pattern template tiré de la documentation de Spring : tt.execute(new TransactionCallbackWithoutResult() { protected void doInTransactionWithoutResult(TransactionStatus status) { updateOperation1(); updateOperation2(); } }); Claude Duvallet — 32/42 Framework
  • 33. Introduction Les services et les modules Les patrons de conception Programmation par template (3/3) Voici comment est déclarée cette classe dans Spring : public abstract class TransactionCallbackWithoutResult implements TransactionCallback { public final Object doInTransaction(TransactionStatus status) { doInTransactionWithoutResult(status); return null; } protected abstract void doInTransactionWithoutResult( TransactionStatus status); } Ce qui satisfait précisément au schéma de classe déclaré ci-dessus. La partie variante est implémentée dans la méthode abstraite, en l’occurrence ce que vous voulez effectuer dans une transaction. Claude Duvallet — 33/42 Framework
  • 34. Introduction Les services et les modules Les patrons de conception Le modèle MVC 1 et 2 (Model View Controller) (1/9) Ce n’est peut-être pas le concept le plus important dans Spring, dans la mesure où il a été largement démocratisé par Struts. Cependant encore trop de programmeurs ont tendance à mélanger toutes les couches, à mettre des traitements métiers dans la jsp, ou encore des servlets dans lesquelles ils mélangent allégrement html, javascript, métier et bien d’autres choses. Étant donné que l’un des objectifs les plus importants de Spring est la séparation des couches, la partie MVC et le concept d’un point de vue général semblent indispensables. Comme cité précédemment l’objectif est de séparer les couches et les technologies. Claude Duvallet — 34/42 Framework
  • 35. Introduction Les services et les modules Les patrons de conception Le modèle MVC 1 et 2 (Model View Controller) (2/9) Pour réaliser la séparation entre les couches et les technologies, le paradigme se divise en trois parties : Le modèle (Model). La vue (View). Le contrôleur (Controller). La couche d’accès aux données est ignorée ici parce que sous jacente à la couche métier. Claude Duvallet — 35/42 Framework
  • 36. Introduction Les services et les modules Les patrons de conception Le modèle MVC 1 et 2 (Model View Controller) (3/9) Le modèle (Model) : C’est la représentation des informations liées spécifiquement au domaine de l’application. C’est un autre nom pour désigner la couche métier. La couche métier ou plutôt la partie qui représente l’information en respectant une structure liée au domaine d’activité, celle qui effectue des calculs ou des traitements amenant une plus value sur l’information brute. Par exemple le calcul du total des taxes sur un prix hors taxe ou encore des vérifications telles que : Y a t-il encore des articles en stock avant d’autoriser une sortie de stock. Claude Duvallet — 36/42 Framework
  • 37. Introduction Les services et les modules Les patrons de conception Le modèle MVC 1 et 2 (Model View Controller) (4/9) La vue (View) : Cette couche ou ce module effectue le rendu de la couche métier dans une forme qui est compréhensible par l’homme, par exemple une page html. Attention souvent le concept MVC est associé à une application web mais ce n’est pas obligatoire : en effet le framework Swing qui permet de produire des interfaces utilisateurs "sous forme de clients lourds" permet également d’implémenter MVC. Le contrôleur (Controller) : Ce module organise la communication entre les deux premiers. Il invoquera une action dans la couche métier (par exemple récupérer les données d’un client) suite à une action de l’utilisateur et passera cette information à la vue (jsp qui affiche les détails). Claude Duvallet — 37/42 Framework
  • 38. Introduction Les services et les modules Les patrons de conception Le modèle MVC 1 et 2 (Model View Controller) (5/9) La couche d’accès aux données est ignorée ici parce que sous jacente à la couche métier. Tout d’abord cela vous permettra de pouvoir debugger et tester plus facilement le code en l’isolant de la partie affichage. En effet, la plupart des bugs sont des problèmes avec l’interface donc ce n’est pas la peine de compliquer encore la donne avec des bugs métiers ou d’accès aux données. De plus, le jour où il vous faudra rendre l’application compatible avec les téléphones portables vous n’aurez qu’à remplacer la partie Vue par une vue qui supporte wml par exemple. Claude Duvallet — 38/42 Framework
  • 39. Introduction Les services et les modules Les patrons de conception Le modèle MVC 1 et 2 (Model View Controller) (6/9) Le modèle MVC version 1 : Claude Duvallet — 39/42 Framework
  • 40. Introduction Les services et les modules Les patrons de conception Le modèle MVC 1 et 2 (Model View Controller) (7/9) Le problème de ce design pattern est la partie concernant les notifications de changement dans le modèle. En effet, si ce point ne pose pas de problème dans le cadre de swing par exemple, où les composants de la vue sont connectés et capables d’intelligence, il n’en est pas de même pour les applications web. Dans le cadre d’une application web, c’est le design pattern MVC2 qui est utilisé car il ne nécessite pas l’emploi du design pattern observer. Ce dernier permet la notification sur les composants : il observe le modèle et permet à la vue de réagir pour se mettre à jour. Claude Duvallet — 40/42 Framework
  • 41. Introduction Les services et les modules Les patrons de conception Le modèle MVC 1 et 2 (Model View Controller) (8/9) Le modèle MVC version 2 : Claude Duvallet — 41/42 Framework
  • 42. Introduction Les services et les modules Les patrons de conception Le modèle MVC 1 et 2 (Model View Controller) (9/9) On remarque que c’est le contrôleur qui devient le module central. De fait, la vue peut à présent se contenter d’afficher sans aucune intelligence. Cependant, même si le design MVC permet de mieux séparer les couches, il ne faut pas oublier qu’il ne s’agit pas de la façon de procéder la plus intuitive. Elle induit donc d’investir du temps dans la réflexion sur la façon de séparer les différentes couches et technologies et surtout de bien réfléchir dans quelle couche s’effectue quel traitement. De plus les frameworks génèrent souvent plus de fichiers et naturellement plus de configuration. Ce surplus de complexité est cependant bien contrebalancé par la flexibilité supérieure, la plus grande fiabilité, une plus grande facilité pour tester et débugger (puisque que l’on peut tester les bouts un à un). Claude Duvallet — 42/42 Framework