Pourquoi JSF appelle plusieurs fois les getters

Disons que je spécifie un composant outputText comme ceci:

<h:outputText value="#{ManagedBean.someProperty}"/>

Si j'imprime un message de journal lorsque le getter pour somePropertyest appelé et charge la page, il est trivial de remarquer que le getter est appelé plus d'une fois par demande (deux ou trois fois c'est ce qui s'est passé dans mon cas):

DEBUG 2010-01-18 23:31:40,104 (ManagedBean.java:13) - Getting some property
DEBUG 2010-01-18 23:31:40,104 (ManagedBean.java:13) - Getting some property

Si la valeur de somePropertyest coûteuse à calculer, cela peut potentiellement être un problème.

J'ai googlé un peu et j'ai pensé que c'était un problème connu. Une solution de contournement consistait à inclure un chèque et à voir s'il avait déjà été calculé:

private String someProperty;

public String getSomeProperty() {
    if (this.someProperty == null) {
        this.someProperty = this.calculatePropertyValue();
    }
    return this.someProperty;
}

Le principal problème avec cela est que vous obtenez des charges de code passe-partout, sans parler des variables privées dont vous pourriez ne pas avoir besoin.

Quelles sont les alternatives à cette approche? Existe-t-il un moyen d'y parvenir sans autant de code inutile? Existe-t-il un moyen d'empêcher JSF de se comporter de cette manière?

Merci pour votre contribution!

Cela est dû à la nature des expressions différées #{}(notez que les expressions standard "héritées" ${}se comportent exactement de la même manière lorsque Facelets est utilisé à la place de JSP). L'expression différée n'est pas immédiatement évaluée, mais créée en tant ValueExpressionqu'objet et la méthode getter derrière l'expression est exécutée à chaque fois que le code appelle ValueExpression#getValue().

Cela sera normalement invoqué une ou deux fois par cycle de demande-réponse JSF, selon que le composant est un composant d'entrée ou de sortie ( découvrez-le ici ). Cependant, ce nombre peut augmenter (beaucoup) plus haut lorsqu'il est utilisé dans l'itération de composants JSF (tels que <h:dataTable>et <ui:repeat>), ou ici et là dans une expression booléenne comme l' renderedattribut. JSF (en particulier, EL) ne mettra pas du tout en cache le résultat évalué de l'expression EL car il peut renvoyer des valeurs différentes à chaque appel (par exemple, lorsqu'il dépend de la ligne datable actuellement itérée).

Évaluer une expression EL et invoquer une méthode getter est une opération très bon marché, donc vous ne devriez généralement pas vous en soucier du tout. Cependant, l'histoire change lorsque vous effectuez une logique DB / métier coûteuse dans la méthode getter pour une raison quelconque. Ce serait à chaque fois réexécuté!

Les meilleures méthodes dans les beans de sauvegarde JSF doivent être conçues de manière à renvoyer uniquement la propriété déjà préparée et rien de plus, exactement selon la spécification Javabeans . Ils ne devraient pas du tout faire de logique DB / métier coûteuse. Pour cela, les @PostConstructméthodes d'écoute du bean et / ou (action) doivent être utilisées. Ils ne sont exécutés qu'une seule fois à un moment donné du cycle de vie JSF basé sur les demandes et c'est exactement ce que vous voulez.

Voici un résumé de toutes les bonnes façons de prérégler / charger une propriété.

public class Bean {

    private SomeObject someProperty;

    @PostConstruct
    public void init() {
        // In @PostConstruct (will be invoked immediately after construction and dependency/property injection).
        someProperty = loadSomeProperty();
    }

    public void onload() {
        // Or in GET action method (e.g. <f:viewAction action>).
        someProperty = loadSomeProperty();
    }           

    public void preRender(ComponentSystemEvent event) {
        // Or in some SystemEvent method (e.g. <f:event type="preRenderView">).
        someProperty = loadSomeProperty();
    }           

    public void change(ValueChangeEvent event) {
        // Or in some FacesEvent method (e.g. <h:inputXxx valueChangeListener>).
        someProperty = loadSomeProperty();
    }

    public void ajaxListener(AjaxBehaviorEvent event) {
        // Or in some BehaviorEvent method (e.g. <f:ajax listener>).
        someProperty = loadSomeProperty();
    }

    public void actionListener(ActionEvent event) {
        // Or in some ActionEvent method (e.g. <h:commandXxx actionListener>).
        someProperty = loadSomeProperty();
    }

    public String submit() {
        // Or in POST action method (e.g. <h:commandXxx action>).
        someProperty = loadSomeProperty();
        return "outcome";
    }

    public SomeObject getSomeProperty() {
        // Just keep getter untouched. It isn't intented to do business logic!
        return someProperty;
    }

}

Notez que vous ne devez pas utiliser le constructeur ou le bloc d'initialisation du bean pour le travail car il peut être invoqué plusieurs fois si vous utilisez un framework de gestion de bean qui utilise des proxys, tels que CDI.

S'il n'y a vraiment pas d'autre moyen pour vous, en raison de certaines exigences de conception restrictives, vous devez introduire le chargement paresseux dans la méthode getter. C'est-à-dire si la propriété est null, puis chargez-la et affectez-la à la propriété, sinon renvoyez-la.

    public SomeObject getSomeProperty() {
        // If there are really no other ways, introduce lazy loading.
        if (someProperty == null) {
            someProperty = loadSomeProperty();
        }

        return someProperty;
    }

De cette façon, la logique DB / métier coûteuse ne sera pas inutilement exécutée à chaque appel getter unique.

Voir également:

• Pourquoi le getter est-il appelé autant de fois par l'attribut rendu?
• Appeler l'action du bean géré JSF au chargement de la page
• Comment et quand dois-je charger le modèle à partir de la base de données pour h: dataTable
• Comment remplir les options de h: selectOneMenu de la base de données?
• Afficher une image dynamique de la base de données avec p: graphicImage et StreamedContent
• Définition et réutilisation d'une variable EL dans la page JSF
• Mesurer le temps de rendu d'une vue JSF après une demande de serveur

Avec JSF 2.0, vous pouvez attacher un écouteur à un événement système

<h:outputText value="#{ManagedBean.someProperty}">
   <f:event type="preRenderView" listener="#{ManagedBean.loadSomeProperty}" />
</h:outputText>

Vous pouvez également inclure la page JSF dans une f:viewbalise

<f:view>
   <f:event type="preRenderView" listener="#{ManagedBean.loadSomeProperty}" />

      .. jsf page here...

<f:view>

J'ai écrit un article sur la façon de mettre en cache le getter de beans JSF avec Spring AOP.

Je crée un simple MethodInterceptorqui intercepte toutes les méthodes annotées avec une annotation spéciale:

public class CacheAdvice implements MethodInterceptor {

private static Logger logger = LoggerFactory.getLogger(CacheAdvice.class);

@Autowired
private CacheService cacheService;

@Override
public Object invoke(MethodInvocation methodInvocation) throws Throwable {

    String key = methodInvocation.getThis() + methodInvocation.getMethod().getName();

    String thread = Thread.currentThread().getName();

    Object cachedValue = cacheService.getData(thread , key);

    if (cachedValue == null){
        cachedValue = methodInvocation.proceed();
        cacheService.cacheData(thread , key , cachedValue);
        logger.debug("Cache miss " + thread + " " + key);
    }
    else{
        logger.debug("Cached hit " + thread + " " + key);
    }
    return cachedValue;
}


public CacheService getCacheService() {
    return cacheService;
}
public void setCacheService(CacheService cacheService) {
    this.cacheService = cacheService;
}

}

Cet intercepteur est utilisé dans un fichier de configuration de ressort:

    <bean id="advisor" class="org.springframework.aop.support.DefaultPointcutAdvisor">
    <property name="pointcut">
        <bean class="org.springframework.aop.support.annotation.AnnotationMatchingPointcut">
            <constructor-arg index="0"  name="classAnnotationType" type="java.lang.Class">
                <null/>
            </constructor-arg>
            <constructor-arg index="1" value="com._4dconcept.docAdvance.jsfCache.annotation.Cacheable" name="methodAnnotationType" type="java.lang.Class"/>
        </bean>
    </property>
    <property name="advice">
        <bean class="com._4dconcept.docAdvance.jsfCache.CacheAdvice"/>
    </property>
</bean>

J'espère que cela vous aidera!

Publié à l'origine sur le forum PrimeFaces @ http://forum.primefaces.org/viewtopic.php?f=3&t=29546

Récemment, j'ai été obsédé par l'évaluation des performances de mon application, le réglage des requêtes JPA, le remplacement des requêtes SQL dynamiques par des requêtes nommées, et ce matin, j'ai reconnu qu'une méthode getter était plus un HOT SPOT dans Java Visual VM que le reste de mon code (ou la majorité de mon code).

Méthode Getter:

PageNavigationController.getGmapsAutoComplete()

Référencé par ui: include in dans index.xhtml

Ci-dessous, vous verrez que PageNavigationController.getGmapsAutoComplete () est un HOT SPOT (problème de performance) dans Java Visual VM. Si vous regardez plus bas, sur la capture d'écran, vous verrez que getLazyModel (), la méthode getter dateable lazy PrimeFaces, est également un point chaud, uniquement lorsque l'utilisateur final fait beaucoup de choses 'opérations paresseuses'. dans l'application. :)

Voir le code (original) ci-dessous.

public Boolean getGmapsAutoComplete() {
    switch (page) {
        case "/orders/pf_Add.xhtml":
        case "/orders/pf_Edit.xhtml":
        case "/orders/pf_EditDriverVehicles.xhtml":
            gmapsAutoComplete = true;
            break;
        default:
            gmapsAutoComplete = false;
            break;
    }
    return gmapsAutoComplete;
}

Référencé par ce qui suit dans index.xhtml:

<h:head>
    <ui:include src="#{pageNavigationController.gmapsAutoComplete ? '/head_gmapsAutoComplete.xhtml' : (pageNavigationController.gmaps ? '/head_gmaps.xhtml' : '/head_default.xhtml')}"/>
</h:head>

Solution: puisqu'il s'agit d'une méthode «getter», déplacez le code et attribuez une valeur à gmapsAutoComplete avant d'appeler la méthode; voir le code ci-dessous.

/*
 * 2013-04-06 moved switch {...} to updateGmapsAutoComplete()
 *            because performance = 115ms (hot spot) while
 *            navigating through web app
 */
public Boolean getGmapsAutoComplete() {
    return gmapsAutoComplete;
}

/*
 * ALWAYS call this method after "page = ..."
 */
private void updateGmapsAutoComplete() {
    switch (page) {
        case "/orders/pf_Add.xhtml":
        case "/orders/pf_Edit.xhtml":
        case "/orders/pf_EditDriverVehicles.xhtml":
            gmapsAutoComplete = true;
            break;
        default:
            gmapsAutoComplete = false;
            break;
    }
}

Résultats des tests: PageNavigationController.getGmapsAutoComplete () n'est plus un HOT SPOT dans Java Visual VM (n'apparaît même plus)

Partager ce sujet, car de nombreux utilisateurs experts ont conseillé aux développeurs JSF juniors de ne PAS ajouter de code dans les méthodes «getter». :)

Si vous utilisez CDI, vous pouvez utiliser les méthodes Producers. Il sera appelé plusieurs fois, mais le résultat du premier appel est mis en cache dans la portée du bean et est efficace pour les getters qui calculent ou initialisent des objets lourds! Voir ici , pour plus d'informations.

Vous pouvez probablement utiliser AOP pour créer une sorte d'aspect qui met en cache les résultats de nos getters pendant une durée configurable. Cela vous éviterait d'avoir à copier et coller du code passe-partout dans des dizaines d'accesseurs.

Si la valeur de someProperty est coûteuse à calculer, cela peut potentiellement être un problème.

C'est ce que nous appelons une optimisation prématurée. Dans les rares cas où un profileur vous indique que le calcul d'une propriété est si extraordinairement coûteux que son appel trois fois plutôt qu'une fois a un impact significatif sur les performances, vous ajoutez la mise en cache comme vous le décrivez. Mais à moins que vous ne fassiez quelque chose de vraiment stupide comme factoriser des nombres premiers ou accéder à une base de données dans un getter, votre code a probablement une douzaine d'inefficacités pires dans des endroits auxquels vous n'avez jamais pensé.

Je conseillerais également d'utiliser un tel cadre comme Primefaces au lieu du stock JSF, ils traitent ces problèmes avant l'équipe JSF e. g dans les primefaces, vous pouvez définir une soumission partielle. Sinon, BalusC l'a bien expliqué.

C'est toujours un gros problème en JSF. Par exemple, si vous avez une méthode isPermittedToBlaBlapour les contrôles de sécurité et que selon vous, vous avez rendered="#{bean.isPermittedToBlaBla}alors la méthode sera appelée plusieurs fois.

Le contrôle de sécurité pourrait être compliqué, par exemple. Requête LDAP etc. Vous devez donc éviter cela avec

Boolean isAllowed = null ... if(isAllowed==null){...} return isAllowed?

et vous devez vous assurer au sein d'une session bean ceci par requête.

Je pense que JSF doit implémenter ici quelques extensions pour éviter les appels multiples (ex: annotation ne @Phase(RENDER_RESPONSE)calle cette méthode qu'une seule fois après la RENDER_RESPONSEphase ...)