[JAVA] Points de révision du code de l'application Spring Boot

J'ai plus d'occasions de toucher Spring Boot au travail. Spring peut créer des applications avec une productivité assez élevée en utilisant pleinement les annotations et les fonctions associées, mais de nombreuses parties entraînent un comportement involontaire lorsqu'elles sont utilisées «d'une manière ou d'une autre». Cette fois, j'aimerais trier le contenu que je commente souvent lors des revues de code (même si ce n'est qu'un point rudimentaire ...).

(1) Est-il divisé en contrôleur / service / référentiel?

Dans Spring, il est recommandé de diviser le traitement de l'ensemble de l'application dans les classes de structure à trois couches suivantes au lieu de les écrire dans une classe spécifique.

Puisque ** Controller ** est le point d'entrée des requêtes, je pense que les développeurs qui sont nouveaux sur Spring le connaîtront, mais si vous créez une application sans penser à rien, vous vous retrouverez avec ** Controller **. Il est facile d'implémenter la logique métier dans **. Ensuite, ** un Fat Controller avec une faible maintenabilité et lisibilité ** sera créé, donc je pense que c'est un point d'être fortement conscient de l'isolement de la logique métier.

Personnellement, je pense qu'il est préférable de se concentrer sur les contenus suivants. L'idée est.

• Controller --Réception des demandes --Validation des paramètres de demande --Service d'exécution --Gestion des exceptions --Créer une réponse
• Service --Exécution de la logique métier --Coopération avec des services externes
• Manipulation des données via le référentiel --Gestion des transactions
• Repository --Manipulation de données

Lors de l'appel de plusieurs types de services dans un contrôleur, le contrôleur a tendance à être volumineux, donc dans ce cas, je pense qu'il est correct de créer une classe ServiceFacade qui sert d'intermédiaire entre le contrôleur et le service.

(2) L'implémentation tient-elle compte du cycle de vie de l'instance?

L'instance gérée par le conteneur DI de Spring est ** Singleton ** par défaut. En d'autres termes, si une variable membre a un état, l'état (ID utilisateur, etc.) sera mélangé parmi les utilisateurs accédant à la même application, et le comportement prévu ne sera souvent pas atteint. Fondamentalement, il est préférable de le rendre sans état, mais en fonction de vos besoins, envisagez de passer à une autre portée prise en charge par Spring.

En passant, s'il s'agit de votre propre classe, vous pouvez modifier la portée en ajoutant l'annotation @Scope.

@Scope("prototype")
@Service
public class SecretService {
 //Mise en œuvre du traitement
}

Comme point de vue de contrôle

• L'instance Singleton a-t-elle un état?
• Utilisez-vous un autre scope (session / prototype) inutilement?

Le point est autour.

(3) Utilisez-vous l'injection de constructeur?

L'injection de dépendances (DI) est inévitable lors de l'utilisation de Spring, mais il existe les deux méthodes suivantes si vous n'écrivez pas de fichier de paramètres. * Je pense que la définition en XML est toujours vivante, mais je pense que peu de gens l'utilisent, donc je vais l'omettre.

• Injection sur le terrain
• Injection de constructeur

L'injection de champ est facile car vous ajoutez simplement @Autowired à la variable membre.

@Autowired
private SecretService service;

Cependant, il est obsolète en raison des inconvénients suivants. * Je me souviens avoir émis un avertissement même au printemps.

• Le mocking n'est pas possible sans utiliser un conteneur DI lors de la création du code de test
• L'attribut final ne peut pas être ajouté au champ et il ne peut pas être immuable.

Par conséquent, à moins de circonstances spéciales (telles que la nécessité d'une dépendance circulaire), utilisez l'injection de constructeur.

private final SecretService service

public MyClass(SecretService service) {
  this.service = service;
}

Si la définition du constructeur est compliquée, vous pouvez également utiliser Lombok.

@AllArgsConstructor
public class MyClass {
  //TODO:la mise en oeuvre
}

(4) Y a-t-il un traitement qui peut être partagé?

Spring fournit HandlerInterceptor et AOP comme mécanisme pour définir le traitement commun transversal. En utilisant ces mécanismes

--Effectuer un prétraitement commun pour toutes les méthodes de toutes les classes sous un package spécifique

• Post-traitement courant avec des méthodes qui retournent un type spécifique de valeur de retour

Dans certains cas, vous n'avez pas à implémenter le traitement en double. Y a-t-il beaucoup de ** sortie de journal ** comme cas courant?

  /**
   *Classe enregistreur
   */
  private final Logger logger = LoggerFactory.getLogger(MyController.class);
  
   
  /**
   *Demander un échantillon de méthode.
   * @param form Form classe
   * @param bindingResult Résultat de la validation
   * @réponse de retour
   */
  @RequestMapping(value = "/", method = RequestMethod.GET)
  public String handleRequest(@Valid MyControllerForm form, BindingResult bindingResult) {
    logger.info("Test d'intercepteur");
    //réduction
  }
}

Plus précisément

@Aspect
@Component
public class MyInterceptor {

  @Before("execution(* jp.co.cross_xross.controller..*.*(..))")
  public void beforeProcess(JoinPoint joinPoint) throws Throwable {
    //Prétraitement
  }
}

Vous pouvez exécuter le "prétraitement", le "post-traitement" et le "traitement alternatif" en spécifiant le nom du package, le nom de la méthode, l'argument et la valeur de retour comme dans.

(5) Avez-vous implémenté vous-même les fonctions fournies par Spring?

Le matériel est bientôt épuisé (rires) Spring fournit des fonctions qui sont souvent implémentées sous forme de sous-projets. Je pense qu'il est préférable d'utiliser la partie qui a tendance à être difficile à mettre en œuvre par vous-même car elle peut être facilement réalisée en utilisant cette fonction.

Postface ...

Je voudrais le confirmer avec les points de révision de code de base de Java. Du point de vue de la révision du code Java pur, je me réfère aux articles de seniors écrits en qiita dans le passé.

• Informations de référence pour un nom de méthode réussi
• Écrivons un petit bon code Java
• Liste de vérification de la révision du code