Como vocês fariam?

Smalltalk Membro desde: 14/02/2008 16:17:15 Mensagens: 3 Offline

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:

E os VO eram classes com um int codigo e String descricao.

Em outro eu vi:

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 é:

onde estas são ENUMS. Porém fica a pergunta: como sincronizar os enums com o banco de dados? E quando removerem/cadastrarem novos?

Thread.start() Membro desde: 19/09/2006 17:52:33 Mensagens: 25 Offline

Olha. eu usaria a primeira opção..

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.

Thread.start() Membro desde: 03/07/2003 11:32:16 Mensagens: 49 Offline

http://blog.fragmental.com.br/2007/01/02/vo-bo-e-tudo-mais-que-voce-nao-deveria-utilizar/

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.

This message was edited 1 time. Last update was at 21/02/2008 09:19:07

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:

Como o sistema que estou trabalhando faz isso mtas vezes com mtos enums criei até uma interface, mas isso é opcional...

andre2k2,

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.

JavaEvangelist Membro desde: 27/03/2007 14:54:31 Mensagens: 353 Offline

nicholas.bittencourt wrote:andre2k2,

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.

Mas sua sugestao é colocar os valores do dominio no banco?

Sim...

This message was edited 1 time. Last update was at 21/02/2008 09:49:16

nicholas.bittencourt wrote:...

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:

E mudaria muito pouco, mas podem mudar?

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.

JavaEvangelist Membro desde: 27/03/2007 14:54:31 Mensagens: 353 Offline

nicholas.bittencourt wrote:Realmente cada dominio é um caso a parte. Mas como disse o thiagorossi:

E mudaria muito pouco, mas podem mudar?

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.

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

Notícias, artigos e o maior fórum brasileiro sobre Java