@Dependent
L'une des annotations de portée du CDI. Le cycle de vie du scope est "Suivez la portée du bean à injecter"
La description ci-dessus. Par exemple, si le bean à injecter est @RequestScoped, le bean de @Dependent se comporte également comme @RequestScoped. Je pense que vous pouvez l'obtenir.
En fait, c'est une erreur!
Par exemple, il existe le code suivant.
MainBean.java
@RequestScoped
public class MainBean {
@Inject
private HogeBean hogeBean;
@Inject
private FugaBean fugaBean;
public void execute(){
hogeBean.setMethod(); // 1
fugaBean.method(); // 3
hogeBean.printMethod(); // 6
}
}
HogeBean.java
@RequestScoped
public class HogeBean {
@Inject
private DependentBean depBean;
public void setMethod(){
depBean.setId("ID défini dans HogeBean"); // 2
}
public void printMethod(){
System.out.println(depBean.getId()); // 7
}
}
FugaBean.java
@RequestScoped
public class FugaBean {
@Inject
private DependentBean depBean;
public void method(){
System.out.println(depBean.getId()); // 4
depBean.setId("ID défini dans FugaBean"); // 5
}
}
DependentBean.java
@Data
@Dependent
class DependentBean{
private String id;
}
Supposons que l'exécution de MainBean soit exécutée de quelque part.
Ce sera comme ça.
Les beans dépendants sont considérés comme des beans @ RequestScoped s'ils sont interprétés comme ayant la même portée que la destination Inject. L'objet @RequestScoped utilise la même instance dans une seule requête La valeur sortie en 4 ci-dessus doit être la valeur définie en 2. et la sortie en 7. doit être la valeur définie en 5.
Le résultat de sortie est donc
console
ID défini dans HogeBean
ID défini dans FugaBean
Devrait être.
Cependant, en réalité, le résultat de sortie est
console
null
ID défini dans HogeBean
Ce sera.
Le temps de survie de @Dependent est
Est la bonne réponse. Le depBean est généré lorsque le hogeBean est généré, Le depBean est détruit lorsque le hogeBean est détruit. Aussi, Le depBean de hogeBean et le depBean de fugaBean sont instances distinctes.
Pour le dire très grossièrement, c'est la même image que la création d'une nouvelle instance dans un champ. (Bien sûr, le traitement est différent dans la réalité car il ne s'agit pas de gestion de l'ICD)
Il n'y a fondamentalement aucun problème avec les références circulaires entre les beans gérés par CDI, mais si vous faites des références circulaires entre les beans @Dependent, une erreur se produira au démarrage du serveur. En effet, le bean dont il dépend est introuvable.
Si vous y réfléchissez bien, que se passe-t-il lorsqu'il y a @ApplicationScoped ou @SessionScoped dans la destination de l'injection? C'est vrai, mais il y avait beaucoup de gens autour de moi qui ont mal compris.
Lorsque vous divisez les composants par domaine, vous pouvez avoir différents états pour chacun, il semble donc que vous puissiez bien l'utiliser.
Recommended Posts