Почему JSF называет методы считывания многократно

Это вызвано природой отложенных выражений # {} (обратите внимание, что "устаревшие" стандартные выражения $ {} ведут себя точно так же, когда Facelets используется вместо JSP). Отложенное выражение не вычисляется немедленно , а создается как объект ValueExpression , и метод получения, стоящий за выражением, выполняется каждый раз, когда код вызывает ValueExpression # getValue () .

Обычно это вызывается один или два раза за цикл запрос-ответ JSF, в зависимости от того, является ли компонент входным или выходным компонентом ( узнайте об этом здесь ).Однако это количество может возрасти (намного) выше при использовании в итерации компонентов JSF (таких как и ) или здесь и там в логическое выражение, подобное атрибуту rendered . JSF (в частности, EL) вообще не кэширует оцененный результат выражения EL, поскольку он может возвращать разные значения при каждом вызове (например, когда он зависит от текущей итерируемой строки данных).

Вычисление выражения EL и вызов метода получения - очень дешевая операция, поэтому вам вообще не следует беспокоиться об этом. Однако ситуация меняется, когда по какой-то причине вы выполняете дорогостоящую БД / бизнес-логику в методе получения. Это будет каждый раз повторяться!

Getter-методы в поддерживающих JSF-компонентах должны быть спроектированы таким образом, чтобы они возвращали только уже подготовленное свойство и ничего более, точно в соответствии со спецификацией Javabeans . Они вообще не должны использовать дорогостоящую БД / бизнес-логику. Для этого следует использовать методы bean-компонента @PostConstruct и / или (действие) слушателя. Они выполняются только один раз в какой-то момент жизненного цикла JSF на основе запросов, и это именно то, что вам нужно.

Вот сводка всех различных правильных способов предварительной установки / загрузки свойства.

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

}

Обратите внимание, что вам не следует не использовать конструктор bean-компонента или блок инициализации для задания, потому что он может быть вызван несколько раз, если вы используете структуру управления bean-компонентами, которая использует прокси, например CDI.

Если у вас действительно нет других способов из-за некоторых ограничительных требований к дизайну, вам следует ввести ленивую загрузку внутри метода получения. Т.е. если свойство равно null , то загрузите и назначьте его свойству, иначе верните его.

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

        return someProperty;
    }

Таким образом, дорогостоящая БД / бизнес-логика не будет без необходимости выполняться при каждом вызове геттера.

См. Также:

• Почему получатель так часто вызывается атрибутом визуализации?
• Вызвать действие управляемого компонента JSF при загрузке страницы
• Как и когда мне следует загрузить модель из базы данных для h: dataTable
• Как заполнить параметры h: selectOneMenu из базы данных?
• Отображать динамическое изображение из базы данных с помощью p: graphicImage и StreamedContent
• Определение и повторное использование переменной EL на странице JSF
• Измерение времени визуализации представления JSF после запроса сервера