Компоненты с областью запроса и инициализация модели данных?

Question

ОБНОВЛЕНИЕ II:Хорошо, мне удалось немного сузить круг.

У меня есть страница с таблицей данных с функциями сортировки и фильтрации, которые находятся в БД.Другими словами, я не использую встроенные функции rich:datatable, которые я использую, а позволяю БД выполнять всю работу.

я работаю с область запроса бобы.Единственные bean-компоненты сеансовой области содержат сортировку и фильтрацию моего интерфейса.

Фильтрация для каждого столбца привязана к определенным полям сеансового компонента.Таким образом, он фактически обновляется на этапе обновления значений модели.

Сортировка потребовала с моей стороны некоторой логики, поэтому я вызываю определенный метод для установки правильных значений сессионному компоненту.Это выполняется на этапе вызова приложения.

Таким образом, любые изменения вступают в силу на этапе ответа на рендеринг, когда страница фактически отображается.

Проблема в том, что таблица данных JSF и прокрутка данных на моей странице вызывают backingBean.getDataModel() которые извлекают данные из БД и dataModel.getRowCount() (который я реализовал для вызова метода, выполняющего отдельный запрос) также в течение Применить значения запроса фаза.Эти два запроса также выполняются во время фазы ответа на рендеринг, которая является единственной фазой, на которой все изменения вступают в силу и запрос выполняется нормально.

Это означает, что для отображения страницы после выполнения фильтрации или сортировки требуется двойное количество запросов.

Я хочу выполнять сортировку и фильтрацию, выполняя только необходимые запросы и не более.

Какие-либо предложения?

Answer 1

Вызов метода получения на этапе применения значений запроса является обязательным, поскольку JSF необходимо знать, какие входные значения были первоначально показаны, чтобы в конечном итоге он мог выполнить любую проверку и/или вызвать любые прослушиватели valuechange на следующем этапе, где это применимо.Также обязательно выяснить, какая кнопка/ссылка была нажата/нажата в любой из строк, чтобы знать, какое действие bean-компонента вызывать на этапе вызова действия.

Но если у вас нет полей ввода, которые должны быть проверены/проверены на изменение значений, а также каких-либо кнопок/ссылок в любой из строк, то я могу себе представить, что запрос на этапе применения значений запроса является, на ваш взгляд, совершенно излишним.

К сожалению, полностью отключить его нельзя.Технически, единственный способ сделать это — поместить компонент данных в область сеанса и выполнить дорогостоящий SQL-запрос (и обновление модели данных) только в конструкторе компонента и в методе действия компонента, чтобы он вызывался только во время работы компонента. конструкция (для первого просмотра) и во время метода действия компонента (во время нового запроса сортировки/фильтрации/любого запроса).Однако недостаток заключается в том, что любые изменения в Datamodel отражаются во всех Windows/Tabs, которые Enduser открывает в том же сеансе, что может вызвать «WTF?» Опыт для эндоусуста.

Томагавк был первым, у которого было хорошее решение этой проблемы в духе preserveDataModel атрибут для <t:dataTable>, что по сути помещает модель данных в дерево компонентов, специфичное для запроса (которое, в свою очередь, уже хранится в области сеанса или в скрытом поле ввода на стороне клиента, в зависимости от того, как вы настроили место хранения состояния представления в face- конфигурация).У RichFaces нет такого прямого решения, но <a4j:keepAlive> делает в основном то же самое.Это повлияет только на «весь» bean-компонент, поэтому, если ваш bean-компонент данных содержит не только модель данных, вы можете рассмотреть возможность его рефакторинга.Следует иметь в виду, что компонент следует проектировать так, как если бы он был компонентом сеанса.

Если модель данных становится большой, я могу себе представить, что это повлияет на память сервера, но это не должно сильно навредить, если вы храните только видимый часть модели данных в памяти (и, следовательно, не весь модель данных, включая все остальные страницы).Посмотрите, перевешивает ли это затраты на выполнение двойных SQL-запросов во время одного HTTP-запроса.

Надеюсь это поможет.