Olá gente,
estou com um probleminha para fazer minha aplicação. Estou usando struts e as minhas “operações básicas” com o banco estão funcionando (insert, delete, update, select). No entanto, surgiu uma grande dúvida sobre como devo fazer as consultas “não triviais”, ou seja, consultas que envolvam joins de tabelas e que o resultado seja exibido num relatório.
Quando tenho que mostrar uma listagem na tela, sempre envio uma coleção para a view e daí uso a tag <logic:iterate> para percorrer a coleção e mostrar o resultados. Isso funciona perfeitamente quando estou listando dados de apenas uma classe do domínio. Minha dúvida é, como faço para mostar uma listagem que veio de uma consulta “não trivial”. Como vou criar uma coleção de objetos e enviar para a view se a minha consulta retorna informações de vários objetos?
Qual é a melhor saída ? Crio uma classe para representar a consulta e daí preencho a coleção com objetos desta classe ? Por exemplo: teria classe “ComprasporCliente” e a minha coleção seria composta por objetos da classe “ComprasporCliente”? Existe outra saída ? Por favor, me ajudem!
Coxon, esse é um dos maiores problemas que enfrento nos sistemas q desenvolvo na empresa em q trabalho!!! , realmente é inviável ficar fazendo uma classe para cada SQL envolvendo vários JOINs… eu acho q nesse caso (por favor, se alguém tem uma solução melhor, diga pq tb quero saber!!!) o lance é chamar a consulta toda numa tag mesmo, ou seja, tu faz essa sua tag só pra consultar esses JOINs… logo, metendo a busca no banco direto na view… mas é isso ai cara, eu me deparo com esse teu mesmo problema muitas vezes, é inviável fazer uma classe pra cada SQL complexo… (na minha opnião) pois pense só, se tu tem vários SQL com JOINs, raramente vai usar um mesmo SQL em vários lugares diferentes no sistema, ou seja, são casos específicos… se alguém tem algo a acrescentar neste tópico, por favor poste, pois eu tb tenho muitas duvidas em qual a melhor maneira de se resolver isso!
O matheus deu uma idéia…
mas eu creio o seguinte, quando vc tem essas consultas malucas, elas nunca são tao repetidas assim, e é interessante ter um objeto para representá-las…
Pode ser o caso de usar um DynaActionForm, (dentro do Struts-config.xml) bom, as vezes num eh possivel dependendo do casa, mas ja ajuda a resolver um monte de problemas neh =) e dai vc num precisa ficar codificando objetos… =) é uma verdadeira mao na roda, e o bom, eh que vc define ele como scopo de seçao, e nao se preocupa mais, vc vai ter aquele estado sempre que quizer =)
Dae…
então é o seguinte… ele serve para vc não precisar declarar classes que serão usadas para casos específicos, e que não são realmente muito úteis… bom a usabilidade é com cada um… normalmente eh usado para recuperar dados de formulários, ou guardar coisas, como dados de um adastro que tem muitas telas, etc etc etc…
Bom, vc só precisa declarar o seu DynaForm dentro do struts-config, e associar ele a uma Action…
bom, não vi nd de mais no DynaForm então jujo… hhehehehe, parece q faz a mesma coisa q uma action do Webwork faria, mas… não entendi onde se aplica aos SQLs com vários JOINs q devem ser listados na tela… hehe :roll:
ahn…
como eu disse antes a soluçao depende de cada um…
Mas da pra fazer para esse caso ai… dependendo do grau de complexidade… faça uma coleçao de Hashtables (Hashtables[]) sei la… depende…
Cada caso eh um caso…
E matheus, como o WebWork trabalha com suas Actions?!
humm… pois é, acho q o ideal mesmo era popular uma classe interna com o retorno dessa consulta, ja q é específico de cada caso, mas ai nao sei se teria como passar a referencia dessa classe pra view…
bem jujo, o Webwork tem um MVC muito simples e claro , tipo, se tu tem o teu form com os inputs nome e idade, tu vai ter uma Action do tipo
[code]public class UserAction implements Action {
private String nome;
private int idade;
public String execute() {
if ( nome == null || nome.length() == 0 || idade < 0 )
return ERROR;
return SUCCESS;
}
// setters e getters
}[/code]
…ai, como no struts, é só mapear ela no xml, e dizer pra onde será direcionado o fluxo da aplicação no caso de SUCCESS ou ERROR (há outras constantes tb, e o legal é q tu pode definir os teus tipos de retorno tb)… esse é o básico dele, tem muito mais coisas legais
Pelo que entendi… não gosto muito(quer dizer odeio!) ter que colocar objetos da view que tenham algum conhecimento sobre outros recursos em outras camadas… Isso fere varios conceitos que vcs jah sabem…
Prefiro ir navegando no grafo se eu tenho:
um Locadora tem clientes.
um cliente possui locacoes que estas locacoes possuem itens.
public class LocadoraBO{
private Collection clientes;
}
public class ClienteBO{
private Collection locacoes;
}
public class LocacaoBO{
private Collection itens;
}
public class ItemBO{
private String titulo;
}
Posso utilizar logic iterate do Struts que ele ira por reflexao navegar no grafo dos objetos e encontrar a informação que desejo…
Vou dar uma fuçada em relação a isso…
Mas já implementei algo parecido.
, realmente é inviável ficar fazendo uma classe para cada SQL envolvendo vários JOINs… eu acho q nesse caso (por favor, se alguém tem uma solução melhor, diga pq tb quero saber!!!) o lance é chamar a consulta toda numa tag mesmo, ou seja, tu faz essa sua tag só pra consultar esses JOINs… logo, metendo a busca no banco direto na view… mas é isso ai cara, eu me deparo com esse teu mesmo problema muitas vezes, é inviável fazer uma classe pra cada SQL complexo… (na minha opnião) pois pense só, se tu tem vários SQL com JOINs, raramente vai usar um mesmo SQL em vários lugares diferentes no sistema, ou seja, são casos específicos… se alguém tem algo a acrescentar neste tópico, por favor poste, pois eu tb tenho muitas duvidas em qual a melhor maneira de se resolver isso! 
