Spring Core

Noyau de Spring.

Notion de couplage fort et couplage faible

Le couplage est une métrique indiquant le niveau d'interaction entre deux ou plusieurs composants logiciels : deux composants sont dits couplés s'ils échangent de l'information.

Injection de dépendances et inversion de contrôle

“Je ne crée pas un objet, je demande à ce qu’on me le fournisse.”, c’est ça l’inversion de contrôle.

Le design pattern Singleton est l’exemple le plus simple : une seule instance autorisée (constructeur privé), qui nous est fournie.

Le design pattern Factory en est un également : l’instance nous est fournie par une couche différente (DAO).

Inversion de contrôle

Inversion of Control.

Elle permet de réduire les dépendances (couplage) entre des objets dont l'implémentation peut varier.

Elle diminue la complexité de gestion du cycle de vie de ces objets (design patterns Singleton et Factory). Le contrôle du flot d'exécution d'une application n'est plus géré par l'application elle-même mais par une structure externe (conteneur).

—> Mise en place : utilisation de l’injection de dépendances.

Injection de dépendances

Dependency Injection.

C’est le mécanisme permettant d'implémenter le principe de l'inversion de contrôle.

Il permet d'éviter une dépendance directe entre deux classes en définissant dynamiquement la dépendance plutôt que statiquement.

Il permet à une application de déléguer la gestion du cycle de vie de ses dépendances et leurs injections à une autre entité.

L'application ne crée pas directement les instances des objets dont elle a besoin : les dépendances d'un objet ne sont pas gérées par l'objet lui-même mais sont gérées et injectées par une entité externe à l'objet.

Implémentation Spring

Spring apporte le "conteneur léger", nommé ApplicationContext, qui permet la prise en charge du cycle de vie des objets (beans) et leur mise en relation.

En client lourd, on crée un environnement Spring en modifiant la classe d’exécution :

@SpringBootApplication
public class Application {
    public static void main(String[] args) {
        ApplicationContext context = SpringApplication.run(Application.class, args);
    }
}

En web, ce n’est pas nécessaire.

Notion de Spring bean

Un bean en Spring est un objet que Spring a créé et qui est disponible dans un conteneur pour une injection.

On peut créer un bean en utilisant des annotations spécifiques grâce auxquelles Spring crée les instances demandées. Si ce n’est pas suffisant (ex : un objet Personne pour le directeur de l’agence), on peut créer un bean par programmation.

On injecte le bean avec l’annotation @Autowired sur le constructeur ou une méthode.

Scope des beans

On définit le scope en annotant la classe qui crée le bean avec @Scope("prototype").

• singleton : scope par défaut

• prototype : une nouvelle instance à chaque injection

• request (uniquement en environnement web) : une nouvelle instance pour chaque requête HTTP

• session (uniquement en environnement web) : une nouvelle instance pour chaque nouvelle session

• application (uniquement en environnement web) : instance liée à un servlet context (ie une application web)

Beans par annotation

Les beans définis par annotation doivent être placés au même niveau ou sous la classe d’application (classe annotée avec @SpringBootApplication).

Annotations principales :

Récupération d’un bean

Un bean est récupéré dans la classe d’exécution grâce à la méthode getBean() rendue disponible par l’instance de ApplicationContext.

Elle prend en argument le nom ou le type du bean.

1. on nomme le bean dans l’annotation de la classe concernée (@Component("unBean")) et à l’appel de getBean(), on caste le bean pour gérer le type de l’objet récupéré : (MaClasseAnnotee) context.getBean("unBean")

2. on donne directement le type du bean en paramètre : context.getBean(MaClasseAnnotee.class)

3. on peut faire les deux à la fois : context.getBean("unBean", MaClasseAnnotee.class)

A l’exécution, Spring nous fournit une instance de notre classe via ce bean (dont il gère le stockage).

• Exemple minimaliste

  Créer un nouveau projet sans starters.

  On est dans un contexte de client lourd.

  Modifier la classe d’exécution Application, annotée @SpringBootApplication, avec la méthode qui charge l’environnement Spring :

  @SpringBootApplication
  public class Application {
    public static void main(String[] args) {
        ApplicationContext context = SpringApplication.run(Application.class, args);
    }
  }

  Dans le package controller, créer une classe HomeController annotée @Controller("homeBean") avec un constructeur vide et une méthode sayHello() :

  @Controller("homeBean")
  public class HomeController {
  	@Autowired //optionnel, par defaut pour Spring Boot
  	public void HomeController() {
  		System.out.println("Constructeur de HomeController");
  	}
  	public void sayHello() {
  		System.out.println("Méthode du contrôleur qui dit bonjour");
  	}
  }

  Dans la classe d’exécution, récupérer le bean du contrôleur et appeler sa méthode :

  • on déclare une instance de HomeController à laquelle on passe le bean grâce à la méthode getBean() rendue disponible par l’instance de ApplicationContext

    ⚠️

    Il faut caster le bean pour gérer le type de l’objet récupéré.

  @SpringBootApplication
  public class Application {
    public static void main(String[] args) {
      ApplicationContext context = SpringApplication.run(Application.class, args);
  
  		HomeController hc_nom = (HomeController) context.getBean("homeBean");
  		HomeController hc_type = context.getBean(HomeController.class);
  		HomeController hc_both = context.getBean("homeBean", HomeController.class);
  		hc_nom.sayHello(); //Méthode du contrôleur qui dit bonjour
  		hc_type.sayHello(); //Méthode du contrôleur qui dit bonjour
  		hc_both.sayHello(); //Méthode du contrôleur qui dit bonjour
    }
  }

• Exemple plus concret

  On est en multicouches : model = bo, controller = ihm, service = bll, repository = dal (+ vue).

  Suite du projet : springboot-basics.

  Classe d’exécution Application, annotée @SpringBootApplication, avec la méthode qui charge l’environnement Spring.

  Package model (bo), on crée :

  ℹ️

  Uniquement des relations unidirectionnelles.

  • une classe Person

  • une classe Genre

  • une classe Movie

  Dans une POJO, on crée au minimum les attributs privés, les getters/setters, un constructeur vide, un constructeur avec tous les paramètres. Dans la vraie vie, on ne met pas forcément l’identifiant dans le constructeur (souvent auto-généré). On ne met pas non plus la méthode toString(), qui sert à déboguer en console mais n’est plus utile en mode web.

  Dans un constructeur vide, on laisse tout par défaut sauf les listes que l’on doit toujours initialiser : “un conteneur peut être vide mais pas nul”. D’ailleurs dans le setter d’un attribut conteneur, on ajoute une condition qui vérifie si l’objet inséré est nul et l’initialise à vide au besoin. Dans un constructeur full, on appelle le setter pour une liste et pas le this pour passer à travers cette vérification.

  Dans un constructeur, on utilise this sauf s’il y a une vérification faite dans le setter, dans ce cas on préfère appeler le setter. Mais dans la vraie vie, la très grande majorité des vérifications se font dans la partie métier (bll, service). Il est possible de faire des vérifications “de bon sens” dans le controller.

  Package service (bll), on crée :

  • une interface MovieService avec les méthodes souhaitées

  BP : “on ne travaille jamais directement avec des classes, mais bien avec des interfaces”

  • une classe bouchon MovieServiceMock @Service avec :

    ℹ️

    On pourra ajouter un profil « dev » afin qu’elle soit désactivée lors de la mise en place de la DAL.

    • les attributs privés listMovies, listGenres, listPeople
    • une méthode privée qui initialise la liste de genres
    • une méthode privée qui initialise la liste des personnes (réalisateurs et acteurs)
    • un constructeur vide qui récupère les deux listes et crée les films
    • les méthodes du contrat de l’interface

  Dans une classe service, on crée les attributs nécessaires, un constructeur vide, les méthodes du contrat de l’interface implémentée, éventuellement d’autres méthodes.

  Dans une classe service mock, on ajoute des données-bouchon dans le constructeur vide.

  Les genres et les participants sont des tables de référentiel : il faut qu’ils existent avant de pouvoir créer un film.

  BP : on externalise un maximum avec des méthodes privées explicites pour améliorer la lisibilité, “un code bien fait est un code qui n’a pas besoin de commentaires”.

  Dans le save(),on fait les vérifications métier et seulement à la fin le add(). On utilise nos propres exceptions pour dire si tout s’est bien passé ou pas.

  Package controller (ihm), on crée une classe MovieController @Controller avec

  • un attribut privé du service

  • un constructeur @Autowired avec le service

  • une méthode pour retourner tous les films

  • une méthode pour trouver un film à partir de son identifiant

  ℹ️

  On devrait retourner un film optional dans le getMovieById() (et dans d’autres) : ça devient la norme. On utilise le type Optionnal pour décrire l’attribut de l’interface (Optional<Movie>) et dans la signature de la méthode :

  @Override
  public Optional<Movie> getMovieById(long id) {
      Optional<Movie> optMovie = Optional.empty();
      for (Movie movie : listMovies) {
          if (movie.getId() == id) {
              optMovie = Optional.of(movie);
              break;
          }
      }
      return optMovie;
  }

  Dans la classe d’exécution fournie, on met à jour le bean qui appelle maintenant un Optional :

  • on déclare une variable Optional<Movie>

  • on fait une condition qui vérifie si la variable a un contenu (isPresent()) et affiche un message adéquouète

  • (+) Il ne peut pas être nul car Optional s’assure que l’objet existe dans tous les cas, on vérifie donc s’il a un contenu.

Beans par programmation

Les beans définis par programmation doivent

• être placés dans un package config > dans une classe de configuration annotée @Configuration

• avoir une méthode annotée @Bean

@Configuration
public class EditeurConfiguration {
  @Bean
  public List<Editeur> avoirListeEditeurs() {

		...

    return listeEditeur;
  }
}

• Exemple

  Créer un nouveau projet sans starters.

  On est dans un contexte de client lourd.

  Modifier la classe d’exécution Application, annotée @SpringBootApplication, avec la méthode qui charge l’environnement Spring.

  Dans le package bo, créer la classe Editeur avec les attributs privés, les constructeurs vide et full, les getters/setters/, la méthode toString.

  public class Editeur {
      private int id;
      private String nom;
  
      public Editeur() {
      }
  
      public Editeur(int id, String nom) {
          this.id = id;
          this.nom = nom;
      }
  
      public int getId() {
          return id;
      }
  
      public void setId(int id) {
          this.id = id;
      }
  
      public String getNom() {
          return nom;
      }
  
      public void setNom(String nom) {
          this.nom = nom;
      }
  
      @Override
      public String toString() {
          return "Editeur{" +
                  "id=" + id +
                  ", nom='" + nom + '\'' +
                  '}';
      }
  }

  Dans le package config, créer la classe EditeurConfiguration annotée @Configuration avec la méthode avoirListeEditeurs() annotée @Bean.

  @Configuration
  public class EditeurConfiguration {
      @Bean
      public List<Editeur> avoirListeEditeurs() {
  
          // un conteneur peut être vide mais pas nul
          List<Editeur> listeEditeur = new ArrayList();
  
          // deux editeurs
          Editeur poche = new Editeur(1, "Poche");
          Editeur hachette = new Editeur(2, "Hachette");
  
          // ajout des editeurs a la liste
          listeEditeur.add(poche);
          listeEditeur.add(hachette);
  
          return listeEditeur;
      }
  }

  Dans la classe d’exécution, récupérer le bean avec getBean() et l’afficher.

  @SpringBootApplication
  public class Application {
      public static void main(String[] args) {
          ApplicationContext context = SpringApplication.run(Application.class, args);
          EditeurConfiguration ec = context.getBean(EditeurConfiguration.class);
          System.out.println(ec.avoirListeEditeurs());
      }
  }

Bonus : CommandLineRunner

= interface Spring Boot avec une méthode d'exécution.

Spring Boot appellera automatiquement la méthode run de tous les beans implémentant cette interface après le chargement du contexte de l'application.

• on modifie la classe d’exécution avec l’annotation @SpringBootApplication, qui doit implémenter CommandLineRunner

• on lui met un attribut annoté @Autowired qui correspondant au bean que l’on veut récupérer

• on garde la méthode main() avec la méthode run qui crée l’instance de sa classe (et charge l’environnement Spring)

• on surcharge la méthode run() qui affichera notre bean à l’exécution de l’application

@SpringBootApplication
public class Application implements CommandLineRunner {

    @Autowired
    private List<Editeur> listeEditeurs;

    public static void main(String[] args) {
        ApplicationContext context = SpringApplication.run(Application.class, args);
    }

    @Override
    public void run(String... args) throws Exception {
        System.out.println(listeEditeurs);
    }
}

Gérer un conflit

S’il existe deux instances d’un même objet dans le conteneur, Spring ne sait pas comment choisir cela crée un conflit.

Par exemple, un bean livreController demande l’injection d’un bean de type livreService par constructeur. Hélas, il existe deux beans correspondant au type demandé : deux classes qui implémente l’interface LivreService, qui sont LivreServiceImpl et LivreServiceMock.

Les conflits peuvent être résolus par annotation :

• @Primary qui rend le bean de la classe annotée prioritaire

• @Qualifier(ImplementationSouhaitee) qui transforme l’injection en une injection par nom
  • si le @Autowired est sur le constructeur, on le met directement dans ses paramètres en précisant le bean qu’on veut : unconstructeur(@Qualifier(ImplementationSouhaitee) …)
  • si le @Autowired est sur l’attribut, on ajoute l’annotation au même endroit

• @Profile("unprofil") qui définit l’association du bean de la classe annotée avec un ou plusieurs profils, qui sont activés dans application.properties avec spring.config.activate.on-profile="unprofil"

• Exemple

  ⚠️

  Seul le code concernant directement l’exemple est fourni.

  Dans le package service, créer les deux classes qui implémentent LivreService : LivreServiceImpl et LivreServiceMock, annotées @Service.

  Par défaut, Spring Boot prend les constructeurs pour l’injection (@Autowired).

  Dans le package controller, créer la classe LivreController annotée @Controller avec

  • un attribut privé livreService annoté @Autowired

  • un constructeur qui injecte le livreService

  Si on lance maintenant : conflit !

  Les différentes options pour gérer le conflit :

  1. ajouter l’annotation @Qualifier("LivreServiceMock") au dessus de l’attribut qui porte

     Ca fonctionne, il sait quel bean choisir. Si on modifie l’annotation @Qualifier("LivreServiceImpl"), il prend l’autre.

  2. choisir une implémentation prioritaire avec @Primary au dessus d’une des deux classes

     Ca fonctionne, il sait quel bean choisir.

  3. définir des profils : @Profile("dev") pour les classes qu’on ne souhaite pas avoir lorsqu’on est en défaut, ici la classe LivreServiceMock

     Attention, on doit définir un profil partout sinon une classe sans rien est prise par défaut dans “default”.

     Ca fonctionne, il choisit le profil par défaut. Si on change la configuration (spring.profiles.active=dev), il prend bien le mock.

En vrac

• BP : il est conseillé de limiter les final, il est préférable de ne pas créer de setter pour les attributs que l’on ne veut pas pouvoir modifer.

• JavaDoc : On génère de la JavaDoc surtout pour les méthodes publiques. On écrit un commentaire javadoc au dessus de la méthode concernée : on décrit ce que fait la méthode et dans quel but, s’il y a des exceptions, les paramètres et le retour. D’autres annotations existent : @since, @see, @author… On génère la documentation avec l’option Generate JavaDoc : un répertoire avec la documentation, sous différents formats. On fournit en général la documentation dans un jar à part.