Запрашиваемые бины и инициализация модели данных? - PullRequest
Новая
       19

Запрашиваемые бины и инициализация модели данных?

3 голосов
/ 26 февраля 2010

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

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

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

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

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

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

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

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

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

Есть предложения?

1 Ответ

1 голос
/ 03 марта 2010

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

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

К сожалению, вы не можете полностью отключить его. Технически, единственное прибегание к этому - поместить компонент данных в область сеанса и выполнить дорогостоящий SQL-запрос (и обновить модель данных) только в конструкторе компонента и в методе действия компонента, чтобы он вызывался только во время компонента. конструкция (для первого вида) и во время метода действия bean-компонента (во время новой сортировки / фильтрации / любого другого запроса). Недостаток, однако, заключается в том, что любые изменения в модели данных отражаются во всех окнах / вкладках, которые конечный пользователь открыл в одном сеансе, что может вызвать "wtf?" опыт для конечного пользователя.

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

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

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

...