Comme j'écris et dis à chaque fois, même maintenant, à l'approche de 2020, il n'y a que deux livres fiables sur le printemps:
Les deux livres (ci-après dénommés «livres») sont de très bons livres, mais les deux ont été publiés en 2016 et la version Spring prise en charge est aussi ancienne que 4.2.
La dernière version à la fin de 2019 est Spring 5.2. Dans cet article, je présenterai quelques points auxquels vous devriez prêter une attention particulière lors de la lecture des livres ci-dessus maintenant.
Consultez le Wiki GitHub (https://github.com/spring-projects/spring-framework/wiki/Spring-Framework-Versions) pour toutes les différences dans 4.x-> 5.x. ..
À partir de Spring 5.0, la ligne de base JDK est 8 (Spring 4 est basé sur JDK 6). Je ne pense pas que les gens qui souhaitent utiliser Spring à partir de maintenant essaieront d'utiliser JDK 6 ou 7.
Spring 5.2 prend en charge jusqu'à JDK 14. Consultez le Wiki GitHub (https://github.com/spring-projects/spring-framework/wiki/Spring-Framework-Versions#jdk-version-range) pour plus d'informations sur la prise en charge des versions JDK et Spring. ..
@ Autowired
doit être abrégéDepuis le printemps 4.2, il existe trois méthodes DI.
Exemple d'injection sur le terrain
@Component
public class Hoge {
@Autowired
Fuga fuga;
}
Exemple d'injection de setter
@Component
public class Hoge {
private Fuga fuga;
@Autowired
public void setFuga(Fuga fuga) {
this.fuga = fuga;
}
}
Exemple d'injection de constructeur
@Component
public class Hoge {
private final Fuga fuga;
@Autowired
public Hoge(Fuga fuga) {
this.fuga = fuga;
}
}
L'injection sur le terrain est souvent utilisée dans les livres. Probablement parce que la quantité de description est la plus petite (peut-être en raison des limites d'espace).
À partir de Spring 4.3, @ Autowired
peut être omis s'il n'y a qu'un seul constructeur dans la classe.
Exemple d'injection de constructeur (4.3 ou version ultérieure)
@Component
public class Hoge {
private final Fuga fuga;
//Parce qu'il n'y a qu'un seul constructeur@Autowired est facultatif!
public Hoge(Fuga fuga) {
this.fuga = fuga;
}
}
Vous pouvez rendre votre classe immuable, utilisez donc l'injection de constructeur autant que possible.
@ GetMapping
au lieu de @ RequestMapping
Utilisez @ RequestMapping
pour écrire des méthodes de classe de contrôleur dans Spring MVC.
4.2 ou plus tôt
@Controller
@RequestMapping("/hoge")
public class HogeController {
@RequestMapping(value = "/index", method = RequestMethod.GET)
public String index() {
return "index";
}
}
Depuis Spring 4.3, des annotations pour chaque méthode de requête HTTP telles que @ GetMapping
et @ PostMapping
ont été introduites. Vous pouvez l'écrire très court!
4.3 ou plus tard
@Controller
@RequestMapping("/hoge") //ici@Le mappage de la demande est OK
public class HogeController {
@GetMapping("/index") // @Utilisez XxxMapping!
public String index() {
return "index";
}
}
Le livre utilise Thymeleaf 2. Pour écrire un écran dans Thymeleaf 2, vous devez l'écrire au format XHTML.
Si vous ajoutez une bibliothèque, vous pouvez en écrire même 2 au format HTML.
2 ou plus tôt
<!DOCTYPE html>
<html xmlns:th="http://www.thymeleaf.org">
<head>
<meta charset="UTF-8" />
<title>écran</title>
</head>
<body>
<form action="index.html" th:action="@{findByFirstName}">
Mot-clé du prénom:<input type="text" name="firstName" />
<input type="submit" value="Chercher" />
</form>
...
Thymeleaf 3 vous permet d'écrire au format HTML par défaut.
3 ou plus tard
<!DOCTYPE html>
<html xmlns:th="http://www.thymeleaf.org">
<head>
<meta charset="UTF-8">
<title>écran</title>
</head>
<body>
<form action="index.html" th:action="@{findByFirstName}">
Mot-clé du prénom:<input type="text" name="firstName">
<input type="submit" value="Chercher">
</form>
...
Je suis content d'avoir oublié /
et il n'y a aucune exception d'exécution!
WebMvcConfigurer
au lieu de la classe WebMvcConfigurerAdapter
Dans Spring 4.3 et versions antérieures, lors de la création d'une configuration Java associée à Spring MVC, elle hérite souvent de la classe WebMvcConfigurerAdapter
.
4.3 ou plus tôt
@Configuration
@EnableWebMvc
public class MvcConfig extends WebMvcConfigurerAdapter {
@Override
public void addViewControllers(ViewControllerRegistry registry) {
...
}
...
}
Depuis Spring 5.0, cette classe est obsolète et il est recommandé d'utiliser l'interface WebMvcConfigurer
implémentée par cette classe.
5.Après 0
@Configuration
@EnableWebMvc
public class MvcConfig implements WebMvcConfigurer {
@Override
public void addViewControllers(ViewControllerRegistry registry) {
...
}
...
}
La classe WebMvcConfigurerAdapter
est une classe qui implémente l'interface WebMvcConfigurer
et remplace toutes les méthodes avec une implémentation vide. Étant basé sur Java 8, toutes les méthodes de l'interface WebMvcConfigurer
sont maintenant des méthodes par défaut avec des implémentations vides. C'est la fin du travail et la classe WebMvcConfigurerAdapter
est obsolète.
[Code source pour WebMvcConfigurer
](https://github.com/spring-projects/spring-framework/blob/master/spring-webmvc/src/main/java/org/springframework/web/servlet/config/annotation /WebMvcConfigurer.java)
@ NotBlank
au lieu de Hibernate Validator @ NotBlank
Avec la prise en charge de Java EE 8 à partir de Spring 5, la version Bean Validation est passée de 1.x à 2.0 (Hibernate Validator 6.0 ou version ultérieure).
Il est possible d'utiliser Bean Validation 1.x avec Spring 5, mais en gros, il est préférable d'utiliser la dernière version.
Bean Validation 2.0 ajoute une nouvelle annotation de contrainte. Certains d'entre eux étaient les propres annotations d'Hibernate Validator et ont été incorporés dans la norme Bean Validation. Plus précisément, les annotations sont les suivantes (toutes dans le package javax.validation.constraints
).
@NotEmpty
@NotBlank
@Email
En conséquence, les propres @ NotBlank
, @ NotEmpty
et @ Email
de Hibernate Validator (tous dans le package ʻorg.hibernate.validator.constraints`) sont obsolètes.
CrudRepository
de Spring Data est incompatible.Depuis Spring Data 2.x, le nom et la valeur de retour de la méthode définie dans CrudRepository
ont été modifiés.
Les changements incluent le support de java.util.Optional
et les changements de nom de méthode.
Dépôt Crud avant 1
public interface CrudRepository<T, ID extends Serializable> extends Repository<T, ID> {
<S extends T> S save(S entity);
<S extends T> Iterable<S> save(Iterable<S> entities);
T findOne(ID id);
boolean exists(ID id);
Iterable<T> findAll();
Iterable<T> findAll(Iterable<ID> ids);
long count();
void delete(ID id);
void delete(T entity);
void delete(Iterable<? extends T> entities);
void deleteAll();
}
2 ou version ultérieure Crud Repository
public interface CrudRepository<T, ID> extends Repository<T, ID> {
<S extends T> S save(S entity);
<S extends T> Iterable<S> saveAll(Iterable<S> entities);
Optional<T> findById(ID id);
boolean existsById(ID id);
Iterable<T> findAll();
Iterable<T> findAllById(Iterable<ID> ids);
long count();
void deleteById(ID id);
void delete(T entity);
void deleteAll(Iterable<? extends T> entities);
void deleteAll();
}
PasswordEncoder
doit toujours être défini explicitementAvant Spring Security 4, le hachage du mot de passe n'était pas effectué sauf si PasswordEncoder
était explicitement spécifié.
À partir de Spring Security 5, DelegatingPasswordEncoder
est utilisé si vous ne spécifiez pas explicitement PasswordEncoder
. Cela lit le préfixe du mot de passe stocké dans la base de données, etc. et délègue le traitement au «PasswordEncoder» approprié.
Je ne pense pas que quiconque ait spécifié PasswordEncoder
en production (je veux le croire). Cependant, dans le code de l'étude, je pense qu'il n'a pas été spécifié par souci de simplicité. Assurez-vous de le spécifier dans Spring Security 5.x ou version ultérieure. Tout ce que vous avez à faire est de définir un bean pour PasswordEncoder
. Bien sûr, les mots de passe stockés dans DB, etc. doivent être hachés avec PasswordEncoder
du même algorithme.
Spécifier l'encodeur de mot de passe
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {
...
@Bean
public PasswordEncoder passwordEncoder() {
return new BCryptPasswordEncoder();
}
}
Pour Spring Boot 1.x-> 2.x, il y a trop de changements à écrire w
Même si tu y penses juste
--Diverses mises à jour de la bibliothèque - Spring 4.x -> 5.x - Spring Data 1.x -> 2.x - Spring Security 4.x -> 5.x - Thymeleaf 2 -> 3 - Hibernate -> 5.4 - Jackson -> 2.10 - Hibernate Validator 5.x -> 6.1 - Flyway 4 -> 6
···etc. Il peut y en avoir beaucoup d'autres.
J'ajouterai les matériaux présentés lors de la session d'étude JSUG. Les deux sont des matériaux précieux, alors veuillez les lire!
Si vous vous en souvenez, je vais l'ajouter un par un.
Recommended Posts