Estou procurando entender mellhor como funciona a paginação de dados em uma pagina web, seja através de um displaytag ou até mesmo de um datatable.
Por exemplo, listagem de produtos de um supermercado:
Ao meu entender, quando chamo uma Action/Controller que executa um método DAO que retornará uma collection de todos produtos(1000 rows), e esse será setada como atributo da minha requisição, imaginemos que configurei meu datatable/displaytag para exibir 10 registros por página, assim, teriamos 100 paginas de 10 registros.
Bom, agora começa minha dúvida:
Relacionado ao caso acima, quando eu clicar na página 2, será realizada uma nova requisição?
Não sei se estou enganado. mas debugando o sistema percebi que uma nova request foi gerada, o que me fez perceber que de 1000 rows retornadas, usei apenas 10, e o resto foi tudo descartado.
Andei lendo sobre paginação sob demanda e notei qua a cada “nova pagina datatable/displaytag” uma requisição é criada, mas a vantagem é que será retornado apenas os registros para cada uma. É correto afirmar isso?
Como fica o servidor nesses casos?? Pelo que compreendi, tais “Collections” são geradas e repassadas para a requisação, acredito que essas não consomem memória RAM do server depois disso, mas, o que ocorrerá caso eu sete esses collections como atributo da sessão?
Cara,depende da sua estrategia de implementação… vou exemplificar pra vc como a eu uso atualmente:
Exemplo do Primefaces…tem lá a datatable normal… se vc usar ela simplesmente colocando a lista la e talz… quando vc “mandar” buscar, ela vai carregar as 1000 linhas na sua lista deixando elas “em memoria”, quando vc passar pra pagina 2,ela só vai mudar a exibição, ou seja os registros já estão em memoria, ela so passa a exibir os 10 seguintes. Vantagem: você só vai “uma” vez no banco. Desvantagem: você tem 1000 registros na memoria, como bem sabemos, o usuario NO MAXIMO deve ir até a 3 pagina, ou seja 30 caras usados, 970 caras na memoria só gastando. Agora, se vc usar essa MESMA datatable, mas colocar um atributo lazy como true… primeiro que sua lista vai ter de ser de LazyDataModel (ou uma filha.), segundo q agora sim o carregamento vai ser “lazy” ou “preguiçoso” numa tradu bem literal. ou seja o usuario buscou, serão trazidos 10 registros pra memoria, quando ele cliclar na pg 2, ele vai no banco buscar mais 10 registros… obs importante, vc tem de implementar esssa logica tá? não é MagicJavaLazy não… HAUSHuhauh A vantagem é q vc não ocupa memoria com coisas desnecessarias, mas tem de ir no banco a cada requisição.
Como o angeliski disse, vai depender da sua implementação.
As duas formas tem suas vantagens e desvantagens.
Trazer tudo e guardar em memória:
A principal vantagem que vejo nessa forma é a rapidez com que vai implementar. Não precisa se preocupar com a implementação da busca por demanda, ordenação… Porém com uma tabela com muitos registros (ou mesmo que sejam pouco mas com muitas informações) irá sobrecarregar o sistema.
Trazer por demanda:
Será um pouco mais demorado e trabalhoso para implementar além de ter que ir ao banco toda vez que mudar de página, porém você terá mais controle do que está sendo mostrado, irá ‘economizar’ memória.
Pode ser que em determinada situação, a primeira opção (trazer tudo de uma vez) seja mais vantajosa. Caso tenha alguma dúvida sobre qual seria a melhor forma de implementar, poste a situação aqui e analisaremos.
Diante das soluções, para mim a melhor situação é a paginação sob demanda, pois se trata de uma aplicação grande e tem um volume de dados muito grande.
cara sempre use paginaçao por demanda, não tem dificuldade nenhuma…
imagine vc trazendo uma tabela com 30 milhões de registros no browser de uma vez? vai pipocar sua tela e seu sistema.