Como vocês fariam?

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.

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.

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:

enum SexoEnum {

    MASCULINO("Masculino", "M"),
    FEMININO("Feminino", "F");

    private String nome;
    private String codigo;

    private SexoEnum(String nome, String codigo) {
        this.nome = nome;
        this.codigo = codigo;
    }
    
    getNome() { return nome; }

    getCodigo() { return codigo; }
}

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:

enum SexoEnum {
    (...)

    public SexoEnum buscarPorCodigo(String codigo) {
        for(SexoEnum sexo : values()) {
            if (sexo.getCodigo().equals(codigo)) return sexo;
        }
         return null;
    }
}

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.

nicholas.bittencourt:

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…

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.

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.

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…