Beans com escopo de solicitação e inicialização do modelo de dados?

Question

ATUALIZAÇÃO II:OK, consegui restringir um pouco.

Tenho uma página com uma tabela de dados com funcionalidades de classificação e filtragem, ambas ocorrendo no banco de dados.Em outras palavras, eu não uso a funcionalidade incorporada do rich:datatable que uso, mas deixo o banco de dados fazer o trabalho.

Eu trabalho com com escopo de solicitação feijões.Os únicos beans com escopo de sessão contêm a classificação e filtragem da minha interface.

A filtragem para cada coluna está vinculada a determinados campos do bean de sessão.Como tal, ele é realmente atualizado durante a fase Atualizar Valores do Modelo.

A classificação exigiu alguma lógica de minha parte, então invoco um determinado método para definir os valores corretos para o bean de sessão.Isso é executado durante a fase Invocar Aplicativo.

Portanto, quaisquer alterações ocorrem durante a fase de resposta de renderização, onde a página realmente é renderizada.

O problema é que a tabela de dados JSF e o datascroller na minha página chamam o backingBean.getDataModel() que buscam os dados do banco de dados e do dataModel.getRowCount() (que implementei para invocar um método que executa uma consulta separada) também durante o Aplicar valores de solicitação Estágio.Essas duas consultas também ocorrem durante a fase de resposta de renderização, que é a única fase em que todas as alterações estão em vigor e a consulta será executada normalmente.

Isso significa que para mostrar uma página após realizar a filtragem ou classificação, ocorre o dobro do número de consultas.

Quero realizar a classificação e filtragem apenas realizando as consultas necessárias e nada mais.

Alguma sugestão?

Answer 1

A chamada do getter durante a fase de aplicação de valores de solicitação é obrigatória porque o JSF precisa saber quais valores de entrada foram mostrados inicialmente para que possa eventualmente fazer qualquer validação e/ou chamar qualquer valuechangelisteners na próxima fase, quando aplicável.Também é obrigatório descobrir qual botão/link foi pressionado/clicado em qualquer uma das linhas para que ele saiba qual ação do bean chamar na fase de ação de invocação.

Mas se você não tiver nenhum campo de entrada que deva ser validado/verificado para alteração de valor, nem botões/links em nenhuma das linhas, posso imaginar que a consulta durante a fase de aplicação de valores de solicitação é completamente supérflua.

Infelizmente, você não pode desativá-lo completamente.Tecnicamente, o único recurso para isso é colocar o bean de dados no escopo da sessão e fazer a cara consulta SQL (e atualização do modelo de dados) apenas no construtor do bean e no método de ação do bean, para que ele seja invocado apenas durante o bean. construção (para a primeira visualização) e durante o método de ação do bean (durante uma nova classificação/filtro/qualquer solicitação).A desvantagem é, no entanto, que quaisquer alterações no datamodel são refletidas em todas as janelas/guias que o enduser abriu na mesma sessão, o que pode causar "WTF?" experiências para o enduser.

Agora, o Tomahawk foi o primeiro que tem uma boa solução alternativa para isso no sabor do preserveDataModel atributo para o <t:dataTable>, que basicamente coloca o modelo de dados na árvore de componentes específicos da solicitação (que por sua vez já está armazenado no escopo da sessão ou em um campo de entrada oculto no lado do cliente, dependendo de como você configurou o local de armazenamento do estado de visualização em faces- configuração).RichFaces não tem uma solução direta como essa, mas o <a4j:keepAlive> faz basicamente o mesmo.Isso afetaria apenas o bean "inteiro", portanto, se o seu bean de dados contiver mais do que apenas o modelo de dados, você poderá refatorá-lo.Você deve ter em mente projetar o bean como se fosse um bean com escopo de sessão.

Se o modelo de dados ficar grande, posso imaginar que isso impacta a memória do servidor, mas isso não deve prejudicar muito se você armazenar apenas o visível parte do modelo de dados na memória (e, portanto, não o inteiro modelo de dados, incluindo todas as outras páginas).Veja se isso compensa o custo de disparar consultas SQL duplas durante uma única solicitação HTTP.

Espero que isto ajude.