DadosUsuario dados_usuario = new DadosUsuario();
int codigo_usuario = dados_usuario.doGravaNovoUsuario(usuario);
Esse código grava um novo usuário…
É assim q se utiliza os daos? instanciando?
Bom… sobre o método getCamposFormularioConsulta() , ele recupera 3 listas de valores (Collections) q serão dispachados para o JSP para serem exibidos em um formulário HTML… para ser mais preciso em campos <select>…
[quote=“dac”]
Bom… sobre o método getCamposFormularioConsulta() , ele recupera 3 listas de valores (Collections) q serão dispachados para o JSP para serem exibidos em um formulário HTML… para ser mais preciso em campos <select>…[/quote]
Então seus formulários no sistema são representações dos formulários web na forma de objetos?
Humm… não entendi muito bem a pergunta…
Mas vou explicar com funciona o cadastro de usuários…
O cadastro é um formulário HTML, ok? Existem algumas caixas de seleção com alguns valores q vem do banco d dados, como por exemplo o Grupo do usuário…
Então o formulário é montado com um campo mais ou menos assim:
Note q o Grupo 1 e o Grupo 2 estão cadastrados no banco d dados…
Para montar isso, o JSP recebe a lista “listaGrupos”.
Dentro dessa lista estão os objetos Grupo.
Utilizo JSTL para montar esse código HTML, por exemplo:
Como é enviado essa lista para o JSP?
A camada de lógica solicita para a fachada a lista de campos de formulários do cadastro de usuários… pelo método getCamposFormularioCadastro();
A fachada solicita para a camada de regras de negócio a mesma lista…
A regra retorna um Hashtable com as listas… cada elemento do Hashtable é uma lista…
Essas listas são solicitadas aos DAOs pela regra…
Por fim, a lógica despacha as listas para o JSP. q apenas exibe as informações…
Desculpe-me se não entendi a pergunta… mas isso responde?
O maior problema que eu consigo perceber é que você está programando para formulários, campos e dados. Do jeito que estava descrito, achei que sua aplicação gerenciava formulários!
Isso é bem comum em linguagens de script (e uma má-prática muito utilizada em Delphi e VB), mas linguagens mais sofisticadas como Java, C/C++ e demais te induzem a pensar diferente.
Essa é a hora da migração mais complexa da aplicação à la ASP/PHP para uma arquitetura de camadas. Você deve extrair os conceitos e regras do seu sistema e criar algo que faça sentido, que espelhe o mundo real. É o que chamamos de Domain Model, ou simplesmente domínio.
Primeiro, esqueça todo e qualquer formulário, eles só são uma característica do HTML, não uma característica do negócio.
Pense no que seu sistema faz.
Ele gerencia usuarios, nao? Então crie uma classe usuario. Esse usuario tem um grupo? Crie um objeto grupo e faça uma associação.
Quando você pergutar ao DAO por a lsita de grupos, pergunte pela lista de grupos, não por dados ou formulários.
Então…
Fiquei um pouco confuso agora…
Pq eu acho q eu já estou fazendo isso…
Eu tenho as classes:
appweb.negocio.Usuario;
appweb.negocio.Grupo;
Beleza? Existe uma associação já…
Tenho também:
appweb.dados.DadosGrupo;
Nessa classe, entre outros métodos existe o método:
public Collection getLista();
Ok? O esquema dos formulários é o seguinte… eu tenho q carregar essa lista para exibir no HTML tá!?
Então tenho a classe:
appweb.regra.RNUsuarios;
Que tem entre outros métodos o método:
public Hashtable getCamposFormularioCadastro();
Esse eskema d formulários não é pedido para o DAO e sim para a camada d regras… pq inicialmente eu tinha um método para cada lista q eu precisava… por exemplo… no cadastro do usuários existe um campo de seleção para os grupos, um para as unidades e um para o nível…
Veja, um usuário pertence a um grupo, uma unidade e tem um nível no sistema, ok? Então eu chamava 3 métodos da regra. Cada um desse método acessava um DAO apropriado e solicitava a lista…
Agora utilizo apenas um método getCamposFormularioCadastro()… q me retorna as listas com os campos do formulário do cadastro de usuários…