Spring est un framework de développement open source pour Java d'entreprise. Les fonctionnalités principales de Spring Framework peuvent être utilisées pour développer n'importe quelle application Java, mais il existe des extensions pour créer des applications Web sur la plate-forme Java EE. Le framework Spring vise à faciliter l'utilisation du développement J2EE et à promouvoir les bonnes pratiques de programmation en activant un modèle de programmation basé sur POJO.

Voici la liste de quelques-uns des grands avantages de l'utilisation de Spring Framework:

• Lightweight- Le ressort est léger en termes de taille et de transparence. La version de base du framework Spring fait environ 2 Mo.

• Inversion of control (IOC)- Le couplage lâche est réalisé au printemps en utilisant la technique d'inversion de contrôle. Les objets donnent leurs dépendances au lieu de créer ou de rechercher des objets dépendants.

• Aspect oriented (AOP) - Spring prend en charge la programmation orientée Aspect et permet un développement cohérent en séparant la logique métier des applications des services système.

• Container - Spring contient et gère le cycle de vie et la configuration des objets applicatifs.

• MVC Framework - Le framework Web de Spring est un framework Web MVC bien conçu, qui offre une excellente alternative aux frameworks Web tels que Struts ou d'autres frameworks Web sur-conçus ou moins populaires.

• Transaction Management - Spring fournit une interface de gestion des transactions cohérente qui peut passer à une transaction locale (en utilisant une seule base de données, par exemple) et passer à des transactions globales (en utilisant JTA, par exemple).

• Exception Handling - Spring fournit une API pratique pour traduire les exceptions spécifiques à la technologie (lancées par JDBC, Hibernate ou JDO, par exemple) en exceptions cohérentes et non contrôlées.

Voici les modules du framework Spring:

• Module de base
• Module Bean
• Module de contexte
• Module de langage d'expression
• Module JDBC
• Module ORM
• Module OXM
• Module Java Messaging Service (JMS)
• Module de transaction
• Module Web
• Module Web-Servlet
• Module Web-Struts
• Module Web-Portlet

Le fichier de configuration Spring est un fichier XML. Ce fichier contient les informations sur les classes et décrit comment ces classes sont configurées et présentées les unes aux autres.

L'inversion de contrôle (IoC) est un concept général, et il peut être exprimé de nombreuses manières différentes et l'injection de dépendance n'est qu'un exemple concret d'inversion de contrôle.

Ce concept dit que vous ne créez pas vos objets mais décrivez comment ils doivent être créés. Vous ne connectez pas directement vos composants et services ensemble dans le code, mais décrivez quels services sont nécessaires par quels composants dans un fichier de configuration. Un conteneur (le conteneur IOC) est alors chargé de tout accrocher.

Les types d'IoC sont -

• Constructor-based dependency injection - La DI basée sur le constructeur est effectuée lorsque le conteneur appelle un constructeur de classe avec un certain nombre d'arguments, chacun représentant une dépendance à une autre classe.

• Setter-based dependency injection - La DI basée sur un Setter est accomplie par le conteneur appelant des méthodes setter sur vos beans après avoir appelé un constructeur sans argument ou une méthode de fabrique statique sans argument pour instancier votre bean.

Puisque vous pouvez mélanger les DI basées sur le constructeur et le Setter, il est judicieux d'utiliser des arguments de constructeur pour les dépendances obligatoires et des setters pour les dépendances facultatives. Notez que l'utilisation d'une annotation @Required sur un setter peut être utilisée pour créer des dépendances requises par les setters.

Les principaux avantages du CIO ou de l'injection de dépendance sont:

• Cela minimise la quantité de code dans votre application.

• Il rend votre application facile à tester car elle ne nécessite aucun singleton ou mécanisme de recherche JNDI dans vos cas de test unitaires.

• Un couplage lâche est favorisé avec un minimum d'effort et un mécanisme moins intrusif.

• Les conteneurs IOC prennent en charge l'instanciation hâtive et le chargement différé des services.

La programmation orientée aspect, ou AOP, est une technique de programmation qui permet aux programmeurs de modulariser des préoccupations transversales, ou un comportement qui traverse les divisions typiques de responsabilité, telles que la journalisation et la gestion des transactions. La construction de base d'AOP est l'aspect, qui encapsule les comportements affectant plusieurs classes dans des modules réutilisables.

Spring IoC crée les objets, les connecte ensemble, les configure et gère leur cycle de vie complet de la création à la destruction. Le conteneur Spring utilise l'injection de dépendances (DI) pour gérer les composants qui composent une application.

Il existe deux types de conteneurs IoC -

• Bean Factory container - Il s'agit du conteneur le plus simple fournissant un support de base pour DI. La BeanFactory est généralement préférée là où les ressources sont limitées comme les appareils mobiles ou les applications basées sur des applets

• Spring ApplicationContext Container - Ce conteneur ajoute des fonctionnalités plus spécifiques à l'entreprise, telles que la possibilité de résoudre des messages textuels à partir d'un fichier de propriétés et la possibilité de publier des événements d'application sur des écouteurs d'événements intéressés.

L'implémentation BeanFactory la plus couramment utilisée est la XmlBeanFactoryclasse. Ce conteneur lit les métadonnées de configuration à partir d'un fichier XML et les utilise pour créer un système ou une application entièrement configuré.

Les trois implémentations couramment utilisées de 'Application Context' sont:

• FileSystemXmlApplicationContext- Ce conteneur charge les définitions des beans à partir d'un fichier XML. Ici, vous devez fournir le chemin complet du fichier de configuration du bean XML au constructeur.

• ClassPathXmlApplicationContext- Ce conteneur charge les définitions des beans à partir d'un fichier XML. Ici, vous n'avez pas besoin de fournir le chemin complet du fichier XML, mais vous devez définir correctement CLASSPATH car ce conteneur recherchera le fichier XML de configuration du bean dans CLASSPATH.

• WebXmlApplicationContext - Ce conteneur charge le fichier XML avec les définitions de tous les beans à partir d'une application Web.

Voici quelques-unes des différences -

• Les contextes d'application fournissent un moyen de résoudre les messages texte, y compris la prise en charge de i18n de ces messages.

• Les contextes d'application fournissent un moyen générique de charger des ressources de fichiers, telles que des images.

• Les contextes d'application peuvent publier des événements sur des beans enregistrés en tant qu'écouteurs.

• Certaines opérations sur le conteneur ou les beans dans le conteneur, qui doivent être gérées de manière programmatique avec une fabrique de bean, peuvent être traitées de manière déclarative dans un contexte d'application.

• Le contexte d'application implémente MessageSource, une interface utilisée pour obtenir des messages localisés, l'implémentation réelle étant enfichable.

Les objets qui forment l'épine dorsale de votre application et qui sont gérés par le conteneur Spring IoC sont appelés beans. Un bean est un objet qui est instancié, assemblé et autrement géré par un conteneur Spring IoC. Ces beans sont créés avec les métadonnées de configuration que vous fournissez au conteneur, par exemple sous la forme de définitions XML <bean />.

La définition du bean contient les informations appelées métadonnées de configuration qui sont nécessaires pour que le conteneur connaisse les éléments suivants -

• Comment créer un haricot
• Détails du cycle de vie de Bean
• Les dépendances de Bean

Il existe trois méthodes importantes suivantes pour fournir des métadonnées de configuration au conteneur Spring -

• Fichier de configuration basé sur XML.
• Configuration basée sur les annotations
• Configuration basée sur Java

Vérifiez l'exemple suivant -

<?xml version = "1.0" encoding = "UTF-8"?>

<beans xmlns = "http://www.springframework.org/schema/beans"
   xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation = "http://www.springframework.org/schema/beans
   http://www.springframework.org/schema/beans/spring-beans.xsd">

   <bean id = "helloWorld" class = "com.tutorialspoint.HelloWorld">
      <property name = "message" value = "Hello World!"/>
   </bean>

</beans>

Lors de la définition d'un <bean> dans Spring, vous avez la possibilité de déclarer une portée pour ce bean. Par exemple, pour forcer Spring à produire une nouvelle instance de bean chaque fois que vous en avez besoin, vous devez déclarer que l'attribut scope du bean estprototype. De la même manière si vous voulez que Spring renvoie la même instance de bean chaque fois que vous en avez besoin, vous devez déclarer l'attribut scope du bean comme étant singleton.

Spring Framework prend en charge les cinq étendues suivantes, dont trois ne sont disponibles que si vous utilisez un ApplicationContext Web.

• singleton - Cela étend la définition du bean à une seule instance par conteneur Spring IoC.

• prototype - Cela permet à une seule définition de bean d'avoir n'importe quel nombre d'instances d'objet.

• request- Cela étend une définition de bean à une requête HTTP. Uniquement valable dans le contexte d'un Spring ApplicationContext Web.

• session- Cela étend une définition de bean à une session HTTP. Uniquement valable dans le contexte d'un Spring ApplicationContext Web.

• global-session- Cela étend une définition de bean à une session HTTP globale. Uniquement valable dans le contexte d'un Spring ApplicationContext Web.

La portée par défaut du bean est Singleton for Spring Framework.

Non, les beans singleton ne sont pas thread-safe dans le framework Spring.

Voici la séquence du cycle de vie d'un haricot au printemps -

• Instantiate - Tout d'abord, le conteneur spring trouve la définition du bean dans le fichier XML et instancie le bean.

• Populate properties - À l'aide de l'injection de dépendances, spring remplit toutes les propriétés comme spécifié dans la définition du bean.

• Set Bean Name - Si le bean implémente l'interface BeanNameAware, spring transmet l'id du bean à la méthode setBeanName ().

• Set Bean factory - Si Bean implémente l'interface BeanFactoryAware, spring passe la beanfactory à la méthode setBeanFactory ().

• Pre Initialization- Aussi appelé post-traitement de bean. S'il y a des bean BeanPostProcessors associés au bean, Spring appelle la méthode postProcesserBeforeInitialization ().

• Initialize beans- Si le bean implémente IntializingBean, sa méthode afterPropertySet () est appelée. Si le bean a une déclaration de méthode init, la méthode d'initialisation spécifiée est appelée.

• Post Initialization - S'il y a des BeanPostProcessors associés au bean, leurs méthodes postProcessAfterInitialization () seront appelées.

• Ready to use - Le bean est maintenant prêt à être utilisé par l'application.

• Destroy - Si le bean implémente DisposableBean, il appellera la méthode destroy ().

Un élément <bean /> à l'intérieur des éléments <property /> ou <constructor-arg /> définit ce qu'on appelle un bean interne. Une définition de bean interne ne nécessite pas d'identifiant ni de nom défini; le conteneur ignore ces valeurs. Il ignore également l'indicateur d'étendue. Les beans internes sont toujours anonymes et ils sont toujours considérés comme des prototypes.

Spring propose quatre types d'éléments de configuration de collection qui sont les suivants -

• <list> - Cela facilite le câblage, c'est-à-dire l'injection d'une liste de valeurs, permettant des doublons.

• <set> - Cela aide à câbler un ensemble de valeurs mais sans aucun doublon.

• <map> - Cela peut être utilisé pour injecter une collection de paires nom-valeur où le nom et la valeur peuvent être de n'importe quel type.

• <props> - Cela peut être utilisé pour injecter une collection de paires nom-valeur où le nom et la valeur sont tous deux des chaînes.

Le conteneur Spring est capable de connecter automatiquement les relations entre les beans collaborant. Cela signifie qu'il est possible de laisser Spring résoudre automatiquement les collaborateurs (autres beans) pour votre bean en inspectant le contenu de BeanFactory sans utiliser les éléments <constructor-arg> et <property>.

La fonctionnalité de câblage automatique a cinq modes qui peuvent être utilisés pour indiquer au conteneur Spring d'utiliser le câblage automatique pour l'injection de dépendances -

• no- Il s'agit du paramètre par défaut, ce qui signifie qu'il n'y a pas de câblage automatique et vous devez utiliser une référence de bean explicite pour le câblage. Vous n'avez rien à faire de particulier pour ce câblage. C'est ce que vous avez déjà vu dans le chapitre Injection de dépendances.

• byName- Autowiring par nom de propriété. Le conteneur Spring examine les propriétés des beans sur lesquels l'attribut autowire est défini sur byName dans le fichier de configuration XML. Il essaie ensuite de faire correspondre et de câbler ses propriétés avec les beans définis par les mêmes noms dans le fichier de configuration.

• byType- Autowiring par type de données de propriété. Le conteneur Spring examine les propriétés des beans sur lesquels l'attribut autowire est défini sur byType dans le fichier de configuration XML. Il essaie ensuite de faire correspondre et de câbler une propriété si son type correspond exactement à l'un des noms de beans dans le fichier de configuration. Si plusieurs haricots de ce type existent, une exception fatale est levée.

• constructor- Similaire à byType, mais le type s'applique aux arguments du constructeur. S'il n'y a pas exactement un bean du type d'argument constructeur dans le conteneur, une erreur fatale est déclenchée.

• autodetect - Spring essaie d'abord de câbler en utilisant autowire par constructeur, si cela ne fonctionne pas, Spring essaie de se connecter automatiquement par byType.

Les limites du câblage automatique sont -

• Overriding possibility - Vous pouvez toujours spécifier des dépendances en utilisant les paramètres <constructor-arg> et <property> qui remplaceront toujours le câblage automatique.

• Primitive data types - Vous ne pouvez pas créer automatiquement des propriétés dites simples telles que des primitives, des chaînes et des classes.

• Confusing nature - Le câblage automatique est moins précis que le câblage explicite, donc si possible préférez utiliser un câblage explicite.

Oui.

Une alternative aux configurations XML est fournie par une configuration basée sur des annotations qui s'appuie sur les métadonnées de bytecode pour le câblage des composants au lieu des déclarations de crochets angulaires. Au lieu d'utiliser XML pour décrire un câblage de bean, le développeur déplace la configuration dans la classe de composant elle-même en utilisant des annotations sur la classe, la méthode ou la déclaration de champ appropriée.

Le câblage d'annotation n'est pas activé dans le conteneur Spring par défaut. Donc, avant de pouvoir utiliser le câblage basé sur les annotations, nous devrons l'activer dans notre fichier de configuration Spring en configurant <context: annotation-config />.

Cette annotation indique simplement que la propriété du bean affecté doit être renseignée au moment de la configuration, via une valeur de propriété explicite dans une définition de bean ou via le câblage automatique. Le conteneur lève BeanInitializationException si la propriété de bean affectée n'a pas été remplie.

Cette annotation fournit un contrôle plus précis sur où et comment l'autowiring doit être effectué. L'annotation @Autowired peut être utilisée pour lancer automatiquement le bean sur la méthode setter, tout comme l'annotation @Required, le constructeur, une propriété ou des méthodes avec des noms arbitraires et / ou plusieurs arguments.

Il peut y avoir une situation où vous créez plus d'un bean du même type et que vous souhaitez en câbler un seul avec une propriété, dans ce cas, vous pouvez utiliser l'annotation @Qualifier avec @Autowired pour supprimer la confusion en spécifiant quel bean exact sera câblé.

Spring a des annotations basées sur JSR-250 qui incluent les annotations @PostConstruct, @PreDestroy et @Resource.

• @PostConstruct - Cette annotation peut être utilisée comme alternative au rappel d'initialisation.

• @PreDestroy - Cette annotation peut être utilisée comme une alternative de rappel de destruction.

• @Resource - Cette annotation peut être utilisée sur des champs ou des méthodes de définition. L'annotation @Resource prend un attribut 'name' qui sera interprété comme le nom du bean à injecter. Vous pouvez dire que cela suit la sémantique d'auto-câblage par nom.

L'option de configuration basée sur Java vous permet d'écrire la plupart de votre configuration Spring sans XML mais à l'aide de quelques annotations basées sur Java.

Par exemple: Annotation @Configurationindique que la classe peut être utilisée par le conteneur Spring IoC comme source de définitions de bean. le@Bean L'annotation indique à Spring qu'une méthode annotée avec @Bean renverra un objet qui doit être enregistré en tant que bean dans le contexte de l'application Spring.

La gestion des événements dans le ApplicationContext est fourni par la ApplicationEvent classe et ApplicationListener interface. Donc, si un bean implémente ApplicationListener , chaque fois qu'un ApplicationEvent est publié dans ApplicationContext, ce bean est notifié.

Spring fournit les événements standard suivants -

• ContextRefreshedEvent- Cet événement est publié lorsque ApplicationContext est initialisé ou actualisé. Cela peut également être déclenché à l'aide de la méthode refresh () sur l'interface ConfigurableApplicationContext.

• ContextStartedEvent- Cet événement est publié lorsque le ApplicationContext est démarré à l'aide de la méthode start () sur l'interface ConfigurableApplicationContext. Vous pouvez interroger votre base de données ou vous pouvez redémarrer / redémarrer toute application arrêtée après avoir reçu cet événement.

• ContextStoppedEvent- Cet événement est publié lorsque ApplicationContext est arrêté à l'aide de la méthode stop () sur l'interface ConfigurableApplicationContext. Vous pouvez effectuer les travaux d'entretien nécessaires après avoir reçu cet événement.

• ContextClosedEvent- Cet événement est publié lorsque ApplicationContext est fermé à l'aide de la méthode close () sur l'interface ConfigurableApplicationContext. Un contexte fermé atteint sa fin de vie; il ne peut pas être actualisé ou redémarré.

• RequestHandledEvent - Il s'agit d'un événement spécifique au Web indiquant à tous les beans qu'une requête HTTP a été traitée.

Un module qui a un ensemble d'API fournissant des exigences transversales. Par exemple, un module de journalisation serait appelé aspect AOP pour la journalisation. Une application peut avoir un certain nombre d'aspects selon les besoins. Dans Spring AOP, les aspects sont implémentés à l'aide de classes régulières (l'approche basée sur le schéma) ou de classes régulières annotées avec l'annotation @Aspect (style @AspectJ).

Concern- Le souci est un comportement que l'on souhaite avoir dans un module d'une application. La préoccupation peut être définie comme une fonctionnalité que nous voulons implémenter. Les questions qui nous intéressent définissent nos préoccupations.

Cross-cutting concern- C'est une préoccupation qui s'applique tout au long de l'application et qui affecte l'ensemble de l'application. par exemple, la journalisation, la sécurité et le transfert de données sont les préoccupations qui sont nécessaires dans presque tous les modules d'une application, d'où des préoccupations transversales.

Cela représente un point dans votre application où vous pouvez intégrer l'aspect AOP. Vous pouvez également dire que c'est l'endroit réel dans l'application où une action sera entreprise à l'aide du framework Spring AOP.

Il s'agit de l'action réelle à entreprendre avant ou après l'exécution de la méthode. Il s'agit d'un morceau de code qui est appelé lors de l'exécution du programme par le framework Spring AOP.

Il s'agit d'un ensemble d'un ou plusieurs points de jonction où un conseil doit être exécuté. Vous pouvez spécifier des pointcuts à l'aide d'expressions ou de modèles comme nous le verrons dans nos exemples AOP.

Une introduction vous permet d'ajouter de nouvelles méthodes ou attributs aux classes existantes.

L'objet étant conseillé par un ou plusieurs aspects, cet objet sera toujours un objet proxy. Aussi appelé objet conseillé.

Le tissage est le processus de liaison d'aspects avec d'autres types d'application ou objets pour créer un objet conseillé.

Le tissage peut être effectué au moment de la compilation, du chargement ou de l'exécution.

Les aspects de printemps peuvent fonctionner avec cinq types de conseils mentionnés ci-dessous -

• before - Exécutez le conseil avant l'exécution d'une méthode.

• after - Exécuter des conseils après l'exécution d'une méthode quel que soit son résultat.

• after-returning - Exécutez le conseil après l'exécution d'une méthode uniquement si la méthode se termine avec succès.

• after-throwing - Exécutez le conseil après l'exécution d'une méthode uniquement si la méthode se termine en lançant une exception.

• around - Exécutez le conseil avant et après l'appel de la méthode conseillée.

Les aspects sont implémentés en utilisant des classes régulières avec une configuration basée sur XML.

@AspectJ fait référence à un style de déclaration d'aspects en tant que classes Java régulières annotées avec des annotations Java 5.

JDBC peut être utilisé plus efficacement à l'aide d'une classe de modèle fournie par Spring Framework appelée JdbcTemplate.

Avec l'utilisation du framework Spring JDBC, le fardeau de la gestion des ressources et de la gestion des erreurs est considérablement réduit. Il laisse donc aux développeurs le soin d'écrire les instructions et les requêtes pour obtenir les données vers et depuis la base de données. JdbcTemplate fournit de nombreuses méthodes pratiques pour effectuer des tâches telles que la conversion de données de base de données en primitives ou objets, l'exécution d'instructions préparées et appelables et la gestion personnalisée des erreurs de base de données.

Spring prend en charge deux types de gestion des transactions -

• Programmatic transaction management- Cela signifie que vous avez géré la transaction à l'aide de la programmation. Cela vous donne une flexibilité extrême, mais c'est difficile à maintenir.

• Declarative transaction management- Cela signifie que vous séparez la gestion des transactions du code métier. Vous n'utilisez que des annotations ou une configuration basée sur XML pour gérer les transactions.

La gestion déclarative des transactions est préférable à la gestion des transactions programmatiques, bien qu'elle soit moins flexible que la gestion des transactions programmatiques, qui vous permet de contrôler les transactions via votre code.

Le framework Spring Web MVC fournit une architecture modèle-vue-contrôleur et des composants prêts à l'emploi qui peuvent être utilisés pour développer des applications Web flexibles et faiblement couplées. Le modèle MVC permet de séparer les différents aspects de l'application (logique d'entrée, logique métier et logique d'interface utilisateur), tout en fournissant un couplage lâche entre ces éléments.

Le framework Spring Web MVC est conçu autour d'un DispatcherServlet qui gère toutes les requêtes et réponses HTTP.

Le WebApplicationContext est une extension du simple ApplicationContext qui possède des fonctionnalités supplémentaires nécessaires pour les applications Web. Il diffère d'un ApplicationContext normal en ce qu'il est capable de résoudre des thèmes et qu'il sait à quel servlet il est associé.

Voici quelques-uns des avantages de Spring MVC par rapport à Struts MVC -

• Le MVC de Spring est très polyvalent et flexible basé sur des interfaces, mais Struts force les actions et les objets Form à un héritage concret.

• Spring fournit à la fois des intercepteurs et des contrôleurs, ce qui permet de prendre en compte le comportement commun lors du traitement de nombreuses requêtes.

• Spring peut être configuré avec différentes technologies de vue telles que Freemarker, JSP, Tiles, Velocity, XLST, etc. et vous pouvez également créer votre propre mécanisme de vue personnalisé en implémentant l'interface Spring View.

• Dans Spring, les contrôleurs MVC peuvent être configurés à l'aide de DI (IOC), ce qui facilite ses tests et son intégration.

• Le niveau Web de Spring MVC est plus facile à tester que le niveau Web Struts, en raison de l'évitement de l'héritage concret forcé et de la dépendance explicite des contrôleurs sur le servlet du répartiteur.

• Struts force vos contrôleurs à étendre une classe Struts, mais pas Spring, il existe de nombreuses implémentations de contrôleur pratiques que vous pouvez choisir d'étendre.

• Dans Struts, les actions sont couplées à la vue en définissant ActionForwards dans un ActionMapping ou globalement. SpringMVC a une interface HandlerMapping pour prendre en charge cette fonctionnalité.

• Avec Struts, la validation est généralement effectuée (implémentée) dans la méthode validate d'un ActionForm. Dans SpringMVC, les validateurs sont des objets métier qui ne dépendent PAS de l'API Servlet, ce qui permet de réutiliser ces validateurs dans votre logique métier avant de conserver un objet de domaine dans une base de données.

Les contrôleurs permettent d'accéder au comportement de l'application que vous définissez généralement via une interface de service. Les contrôleurs interprètent l'entrée de l'utilisateur et la transforment en un modèle qui est représenté à l'utilisateur par la vue. Spring implémente un contrôleur de manière très abstraite, ce qui vous permet de créer une grande variété de contrôleurs.

L' annotation @Controller indique qu'une classe particulière joue le rôle d'un contrôleur. Spring ne vous oblige pas à étendre une classe de base de contrôleur ou à référencer l'API Servlet.

L' annotation @RequestMapping est utilisée pour mapper une URL à une classe entière ou à une méthode de gestionnaire particulière.

Il existe deux façons d'accéder à la mise en veille prolongée à l'aide du ressort -

• Inversion de contrôle avec un modèle Hibernate et un rappel.

• Extension du support HibernateDAOS et application d'un nœud d'intercepteur AOP.

Spring prend en charge les ORM suivants -

• Hibernate
• iBatis
• JPA (API de persistance Java)
• TopLink
• JDO (objets de données Java)
• OJB