Dlaczego JSF dzwoni do getterów wielokrotnie

W JSF 2.0 możesz dołączyć listener do zdarzenia systemowego

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

Alternatywnie możesz dołączyć stronę JSF do znacznika f:view

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

      .. jsf page here...

<f:view>

Napisałem Artykuł o tym, jak buforować JSF beans getter za pomocą Spring AOP.

Tworzę prostą MethodInterceptor, która przechwytuje wszystkie metody opatrzone specjalną adnotacją:

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;
}

}

Ten interceptor jest używany w pliku konfiguracyjnym sprężyny:

    <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>

Originally posted in PrimeFaces forum @ http://forum.primefaces.org/viewtopic.php?f=3&t=29546

Ostatnio miałem obsesję na punkcie oceny wydajności mojej aplikacji, dostrajania zapytań JPA, zastępowania dynamicznych zapytań SQL zapytaniami nazwanymi i właśnie dziś rano zauważyłem, że metoda getter była bardziej gorącym punktem w wizualnej maszynie wirtualnej Java niż reszta mojego kodu (lub większość mojego kodu).

Metoda gettera:

PageNavigationController.getGmapsAutoComplete()

Odwołany przez ui: include in in indeks.xhtml

Poniżej zobaczysz, że PageNavigationController.getGmapsAutoComplete() jest HOT SPOT (problem wydajności) w Java Visual VM. Jeśli spojrzysz dalej w dół, na screenie capture, zobaczysz, że getLazyModel (), metoda PrimeFaces lazy datatable getter, jest również gorącym punktem, tylko wtedy, gdy użytkownik końcowy robi wiele rzeczy/operacji/zadań typu "lazy datatable" w aplikacji. :)

Patrz (oryginalny) kod poniżej.

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;
}

Indeks.xhtml:

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

Rozwiązanie: ponieważ jest to metoda' getter', przenieś kod i przypisz wartość do gmapsAutoComplete przed wywołaniem metody; patrz kod poniżej.

/*
 * 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;
    }
}

Wyniki testu: PageNavigationController.getGmapsAutoComplete() nie jest już HOT SPOT w Java Visual VM (nawet się już nie pojawia)

Dzielenie się tym tematem, ponieważ wielu ekspertów doradziło młodszym programistom JSF, aby nie dodawali kodu w metodach 'getter'. :)

Prawdopodobnie mógłbyś użyć AOP do stworzenia jakiegoś aspektu, który buforował wyniki naszych getterów przez konfigurowalną ilość czasu. Zapobiegłoby to konieczności kopiowania i wklejania kodu kotła w dziesiątkach accesorów.

Jeśli używasz CDI, możesz użyć metod producentów. Będzie on wywoływany wiele razy, ale wynik pierwszego wywołania jest buforowany w obszarze bean i jest wydajny dla getterów, które obliczają lub inicjalizują ciężkie obiekty! Zobacz tutaj , aby uzyskać więcej informacji.

To nadal duży problem w JSF. Fo przykład jeśli masz metodę isPermittedToBlaBla do kontroli bezpieczeństwa i w Twoim widoku masz rendered="#{bean.isPermittedToBlaBla}, to metoda będzie wywoływana wiele razy.

Kontrola bezpieczeństwa może być skomplikowana np. Zapytanie LDAP itp. Więc musisz tego unikać z

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

I musisz zapewnić w trakcie sesji to na żądanie.

Ich zdaniem JSF musi zaimplementować tutaj niektóre rozszerzenia, aby uniknąć wielu wywołań (np. adnotacja @Phase(RENDER_RESPONSE) ta metoda tylko raz po RENDER_RESPONSE Faza...)

Jeśli wartość someProperty jest kosztowne do obliczenia, to może to może być problem.