Relatórios com Jasper usando SQL ou JavaBean?

10 respostas
Bear

Olá amigos do GUJ :slight_smile:

Na faculdade estamos estudando a geração de relatorios com jasperReports e vimos duas abordagens, utilizando SQL e outra com JavaBeanDataSource, mas ficamos com duvidades quais são os beneficios da primeira abordagem ou da segunda abordagem, ou dificuldades também.

Desde já agradeço a ajuda!

10 Respostas

blackout

Então…

Eu, particularmente, acho mais interessante a abordagem de gerar relatórios utilizando SQL direto no relatório.

Utilizar SQL direto no relatório é interessante porque você tira bastante acoplamento desse relatório com a aplicação. Essa abordagem também possibilita a criação de uma classe genérica para mais de um relatório. Aí sim é tirado todo o acoplamento do relatório com o a aplicação, e na manutenção só é necessário mexer efetivamente no arquivo jasper. Outra vantagem é que, na criação ou alteração do relatório, não é necessário estar com a aplicação rodando pra ver o relatório funcionar. Pois como o SQL está no relatório, basta que o banco esteja ok, configura-lo no iReport e mandar o relatório rodar no iReport.

Resumindo, olhando pelo ponto de vista acima, eu vejo que a abordagem SQL é menos “complexa”, pois você pode ver mais claramente a distinção do que é o relatório e o que é aplicação e sabe mais rapidamente onde mexer caso necessário.

Acabei falando somente de prós da abordagem SQL e contras do JavaBean. Mas comparando as duas, no meu ponto de vista seria isso.

A

Desenvolvo usando iReport e sempre com SQL dentro do relatório. Mas acho importante conhecer os dois modos. Estes dias por exemplo, estou trabalhando numa aplicação que lê um arquivo, faz umas checagens e deve mostrar o resultado desse processo. É o tipo de situação que cabe usar JavaBeans, porque não há consulta a banco de dados.

marcusco

Boa tarde a todos.

No meu caso considero o javaBeans a melhor forma, pois, modelando
adequadamente o problema, basta apenas importar o jar.
Considero que listagens simples podem ser feitas por SQL,
mas relatórios mais elaborados acho complicado.
Muitos programadores acham que podem resolver todos
os problemas de relatórios com SQL, o que não acontece
na vida real.

lele_vader

Pode-se rodar uma classe de teste e rodar um relatório com java bean collection datasource sem a aplicação estar funcionando.

J

marcusco:
Boa tarde a todos.

No meu caso considero o javaBeans a melhor forma, pois, modelando
adequadamente o problema, basta apenas importar o jar.
Considero que listagens simples podem ser feitas por SQL,
mas relatórios mais elaborados acho complicado.
Muitos programadores acham que podem resolver todos
os problemas de relatórios com SQL, o que não acontece
na vida real.

Exatamente,
Eu também prefiro por javaBeans… o relatório se torna uma camada de apresentação “burra” e basta criar um Mock para fornecer dados de teste e testar inclusive a performance para preenchimento do relatório.
Entretanto, há casos que os relatórios são tão simples, que acaba valendo a pena colocar o SQL direto… mesmo o relatório ficando acoplado ao banco de dados, de nada ele serviria sem o banco.
Há casos também que os dados tem que vir de lugares mistos e ainda casos onde o pré-processamento é pesado. Desta forma fazer com JavaBean da total flexibilidade.

A

Também prefiro utilizar a abordagem com beans.

Isso me permite reaproveitar regras de negócio na geração dos dados.

O relatório vira só um template para exibição dos dados.

drsmachado

Quem defende SQL no relatório esquece que um relatório pertence à camada de visão, logo, se trabalha num modelo MVC, deve esquecer isso, pois, visão não acessa diretamente a camada de persistência.

Gerva

Quando precisar obrigatóriamente tratar os dados antes da chamada, realmente acho melhor usar beans, mas quando não, uso sempre SQL direto no relatório mesmo, seu relatório não vai ficar dependente da sua aplicação ou de classes específicas, tenho uma classe genérica que recebe os parametros e envia pro relatório, só isso…

Mas cada um tem sua opinião e preferencia, e realmente, você deve conhecer bem os 2

R

uma coisa que ajuda muito no bean e a possibilidade de varias acessos simultaneas ao banco

Bear

Muito obrigado a todos pelas valorosas contribuições! :smiley:

No projeto em que estou trabalhando tivemos que usar bean. Tinhamos subreports que precisavam receber varias coleções de dados, foi preciso passa-las para o relatorio principal para então relacionar aos fields nos subreports, gostei dessa abordagem, mas achei interesantes também os argumentos pro SQL, concordo que é importante saber ambas as opções para ter um leque maior de possibilidade para soluções de relatórios.

Criado 27 de junho de 2012
Ultima resposta 29 de jun. de 2012
Respostas 10
Participantes 10