Qual a melhor forma de se apresentar coisas que na tela seriam combos fixas? E mudaria muito pouco, mas podem mudar?
Por exemplo:
Pessoa
sexo [M, F]
escolaridade [Analfabeto, Primeiro Grau Incompleto, Primeiro Graru?]
area [EXATAS, HUMANAS?]
Uma vez eu vi num sistema:
public class Pessoa {
private SexoVO sexo;
private EscolaridadeVO escolaridade;
private AreaVO area;
}
E os VO eram classes com um int codigo e String descricao.
Em outro eu vi:
public class Pessoa {
private int sexo;
private int escolaridade;
private int area;
}
Daí como eu vou saber que número é o que? No caso eles só mapearam em uma classe Constantes os itens que fossem parte do negócio, por exemplo, se for EXATA faz isso? Mas se HUMANAS não tivesse algo em específico, nem entrava nas constantes.
O que eu acho mais interessante é:
public class Pessoa {
private SEXO sexo;
private ESCOLARIDADE escolaridade;
private AREA;
}
onde estas são ENUMS. Porém fica a pergunta: como sincronizar os enums com o banco de dados? E quando removerem/cadastrarem novos?
Mas não criaria um tipo de objeto pra cada caso… por ex., um VO pra pessoa, otro pra outra coisa, outro pra outra coisa.
Vc poderia fazer um genérico q receba um int e uma String (q eh o q vai no combo). Depois, vc pode criar métodos que retornem o VO com os dados q vc precisa. Por ex, um método carregarComboSexo(), que retornaria uma Collection do tipo do VO com todas as opções disponíveis.
Acho que eu ficaria com a segunda opção.
Por mais que a primeira seja válida, voce estaria fazendo classes cada vez mais pesadas e que, se colocadas em uma sessão do usuário, só serviriam para sobrecarregar o sistema.
Uma solução seria criar uma classe de serviço resposável por prover os dominios do sistema. Assim voce pediria a ela o dominio de ESCOLARIDADE e ele retornaria um HashMap (ou similar) com a associação chave valor. Guardando essa informaçao em cache, voce nao precisa ir sempre no banco e garante uma certa performance no sistema. Para recuperar as descrições, basta mais um metodo onde voce informa o dominio e a chave e ele retorna o texto equivalente.
Eu ficaria com a terceira. O caso dos enums… para sincronizar eles com o banco eu faco assim, coloco no enum um campo tipo codigo ou algo assim, que é esse o valor gravado no banco. O enum fica assim:
Quando vou persistir os dados eu uso algo: pessoa.getSexo().getCodigo(). E o codigo (M/F) vai para o banco… quando recuperar do banco vc tera M ou F entao é só fazer o caminho inverso buscando o valor no enum pelo codigo… resolvo isso colocando um metodo que busca o elemento do enum por codigo:
[code]enum SexoEnum {
(…)
public SexoEnum buscarPorCodigo(String codigo) {
for(SexoEnum sexo : values()) {
if (sexo.getCodigo().equals(codigo)) return sexo;
}
return null;
}
}[/code]
Como o sistema que estou trabalhando faz isso mtas vezes com mtos enums criei até uma interface, mas isso é opcional…
O problema é que, a cada alteracao no dominio, voce precisaria enviar novamente a aplicação toda ao cliente. Utilizando uma abordagem com os dominios em banco de dados construidos dinamicamente de tempos em tempos, um simples SQL já atualiza as informações e não precisa parar a aplicação e aumentar o risco de novos erros de codigo.
O problema é que, a cada alteracao no dominio, voce precisaria enviar novamente a aplicação toda ao cliente. Utilizando uma abordagem com os dominios em banco de dados construidos dinamicamente de tempos em tempos, um simples SQL já atualiza as informações e não precisa parar a aplicação e aumentar o risco de novos erros de codigo.[/quote]
Mas sua sugestao é colocar os valores do dominio no banco?
Não gosto muito de uma abordagem assim para dominios como sexo (que nunca mudam) vc ficaria criando mtas tabelas q as vezes nunca mudam…
No caso dos enuns havendo mudança no dominio altera-se os enum e manda pro cliente apenas o .jar do dominio.
Realmente cada dominio é um caso a parte. Mas como disse o thiagorossi:
Enviando apenas o jar para o cliente voce gera oportunidade para erros, a nao ser que o cliente seja você mesmo com acesso ao servidor para colocar o jar no lugar certo.
[quote=nicholas.bittencourt]Realmente cada dominio é um caso a parte. Mas como disse o thiagorossi:
Enviando apenas o jar para o cliente voce gera oportunidade para erros, a nao ser que o cliente seja você mesmo com acesso ao servidor para colocar o jar no lugar certo.[/quote]
No meu caso enviar para o cliente não é bem o termo… uma aplicação no cliente atualiza e configura automaticamente… é verdade q a propensão a erros é maior… mas é que no meu caso tenho mais de 800 tabelas e mais milhares de views e procedures pra dar manutenção… dai é um pouco ruim criar mais tabelas para dominio…