Consultas não triviais

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!

Bom…

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 =)

Buenas eh isso ai… tudo depende de sua aplicação!

Abraços!!

ae jujo, qual é o lance do DynaActionForm do Struts? Não conheço, mas ja ouvi falar…

:pensativo:

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…

<form-beans>

<form-bean name=“theForm” type=“org.apache.struts.action.DynaActionForm”>

<form-property name=“id” type=“java.lang.String”/>				

<form-property name=“nome” type=“java.lang.String”/>

</form-bean>

</form-beans>

<action-mappings>

<action path="/Action" name=“theForm” type=“meu.pacote.minhaClasse”>
<forward name=“success” path="/tile.minhaPagina"/>
</action>

</action-mappings>

Vc pode colocar tbm o type do seu form como:
org.apache.struts.validator.DynaValidatorForm, etc etc…

bom depois dentro da sua Action eh soh chamar ele conforme vc faria com os outros =)

Espero que tenham entendido, qqr dúvida peça ai, que eu detalho mais dai =)

acho que vou fazer um tutorial sobre uso de DynaForms, e tiles… será que rola?!

Abraços!!!

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:

tenho o mesmo problema…

qdo alguem achar uma boa solução, vai ajudar mta gente! hehehe

flw ae!

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?!

mostra ai… fiquei curioso =) hehehe

Abraço!!!

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

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
}

..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.

E funcionou tranquilo.