DAOS, Model e JDBC

Cara usando jdbc puro sim, com hibernate vc pega o objeto por completo dai vc vai trabalhando de acordo com a sua necessidade

abrçs

Opá no spring tem uns trem de JDBC bem legalzinho ! de uma olhada acho q pode adiantar teu lado

http://static.springframework.org/spring/docs/2.0.x/reference/jdbc.html

Vou dar uma olhada…
estava penssando em usar reflection para populalos dinamicamente…

Você pode tentar criar uma solução utilizando Reflexão. Assim você identificaria a classe, criaria uma instância desta, identificaria os métodos a serem invocados e popularia o objeto com base no ResultSet. Acho que isso resolveria o seu problema, se é que eu entendi corretamente.

Abraço.

maniacs:

Vou dar uma olhada…
estava penssando em usar reflection para populalos dinamicamente…

Se seus objetos de modelos são espelhos identicos das tabelas do banco de dados, você poderia usar reflection tranquilamente, ainda mais que você tem deixado o nome dos atributos na mesma convenção do banco.

O problema é se você tiver por exemplo, uma classe(leia objeto) que é persistida em varias tabelas ou varias tabelas que são carregadas em um unico objeto. Ai a coisa complica.

Em todo caso você ja tentou usar algum gerador de DAO? Acho que seria bom para seu caso

ddduran:

maniacs:

Vou dar uma olhada…
estava penssando em usar reflection para populalos dinamicamente…

Se seus objetos de modelos são espelhos identicos das tabelas do banco de dados, você poderia usar reflection tranquilamente, ainda mais que você tem deixado o nome dos atributos na mesma convenção do banco.

O problema é se você tiver por exemplo, uma classe(leia objeto) que é persistida em varias tabelas ou varias tabelas que são carregadas em um unico objeto. Ai a coisa complica.

Em todo caso você ja tentou usar algum gerador de DAO? Acho que seria bom para seu caso

Gerador de dao ?
sim classe mapeada / tabela no banco são mesmos nomes de fields…

maniacs:

Estou usando JDBC em um sistema com banco legado (em um sistema comercial Delphi)
(ja usei hibernate mas o mapeamento não foi muito trivial para este banco)

O que faltou? Se fosse vc insistiria com Hibernate. Vc apanha um pouco no começo, mas depois é só correr pro abraço.

É que ja fiz uma implementação no hibernate para um modelo parecido de banco de dados (outro sistema da empresa) e foi realmente trabalhoso o mapeamento

mas os DAOS foram faceis, ja que usei um GenericDAO no hibernate que fazia praticamante tudo que eu precisava…
mas ainda assim o Mapeamento era trabalhoso ja que uma unica tabela tinha mais de 100 fields e varios relacionamentos
pior que o banco é bem modelado, mas o sistema é complexo e o mapeamento é grande…

maniacs:

Estou usando JDBC em um sistema com banco legado (em um sistema comercial Delphi)
(ja usei hibernate mas o mapeamento não foi muito trivial para este banco)

por isso usar JDBC seria a melhor saida.

maniacs:

Mas gostaria de saber vocês pupulam o objecto modelo;

com set um por um ?

maniacs:

ja que esta tabela por exemplo tem 83 fileds e todo provavelmente serão usados…
é algo que consome algum tempo para fazer as operações dos daos

Não é o meu conhecimento sobre hibernate que me limita, ja que eu o uso em outros tantos sistemas sem problemas
no meu ver o hibernate em casos como esse, com banco legado não é prodututivo e acaba complicando o desenvolvimento
por isso ainda estou convencido que JDBC é a melhor solução para este caso

“Consome tempo porque você não quer aprender a utilizar o Hibernate. O tempo que vai perder fazendo essas coias nesse projeto que você está já vale aprender o Hibernate”

Eu sei usar hibernate e não é essa a questão…

maniacs:

Estou usando JDBC em um sistema com banco legado (em um sistema comercial Delphi)
(ja usei hibernate mas o mapeamento não foi muito trivial para este banco)

por isso usar JDBC seria a melhor saida.

Mas gostaria de saber vocês pupulam o objecto modelo;

com set um por um ?

Cliente cliente = new Cliente();
cliente.setCD_CLIENTE(rs.getString("CD_CLIENTE"));
cliente.setNM_CLIENTE(rs.getString("NM_CLIENTE"));
// ....

Se os seus objetos cumprem essa regra de que o nome da coluna é igual ao nome da propriedade
ou seja setXYZ seta a coluna XYZ vc pose usar reflection.

public void populate(Object objectoAPopular, ResultSet rs){


//obtém todos os métodos da classe

Method[] methods = objectoAPopular.getClass().getDeclaredMethods();
//itera todos. e aqueles que começam com set invoca 
for (int i = 0 ; i < methods.length; i++){
          Method m = methods[i];
          if (m.getName().startsWith("set")){
                   //obtem o resto do nome
                 final  String coluna = m.getName().subString(4).toUpperCase(); // tudo depois de set
                 final Class tipoDeDado = m.getParameterTypes()[0]; // só tem um parametro
                 m.invoke(  objectoAPopular , readFromResult(coluna, tipoDeDado);
          }   
        
}

}

private Object[] readFromResult(String coluna, Class tipo){

          // aqui existem outras formas só para dar uma ideia

          if (tipo.equals(String.class)){
                  return new Object[]{rs.getString(coluna)}; 
          }  else if (tipo.equals(Integer.class)){
                  return new Object[]{rs.getInt(coluna)}; 
          } // etc...

}

Se os nomes das colunas são são exactamente iguais aos dos métodos, pode incluir um mapeamento simples num arquivo properties, por exemplo.

tem scripts que geram automaticamente o mapeamento e a classe persistente… não lembro de cabeça o nome mas isto pode lhe ajudar… dai não precisa gerar os mapeamentos na mão… apenas colocar o hbm no hibernateconfig…

Eu sendo você continuaria a insistir no mapeamento por Hibernate.
Você pode perder o mesmo tempo, ou até mais, se decidir por JDBC.

Vou estudar a possibilidade do hibernate / JPA então…
Assim que eu puder eu posto minha solução

É que ja fiz uma implementação no hibernate para um modelo parecido de banco de dados (outro sistema da empresa) e foi realmente trabalhoso o mapeamento

mas os DAOS foram faceis, ja que usei um GenericDAO no hibernate que fazia praticamante tudo que eu precisava…
mas ainda assim o Mapeamento era trabalhoso ja que uma unica tabela tinha mais de 100 fields e varios relacionamentos
pior que o banco é bem modelado, mas o sistema é complexo e o mapeamento é grande…

As suas classes tambem possuem +/- 100 atributos ?? :shock:

É que ja fiz uma implementação no hibernate para um modelo parecido de banco de dados (outro sistema da empresa) e foi realmente trabalhoso o mapeamento

mas os DAOS foram faceis, ja que usei um GenericDAO no hibernate que fazia praticamante tudo que eu precisava…
mas ainda assim o Mapeamento era trabalhoso ja que uma unica tabela tinha mais de 100 fields e varios relacionamentos
pior que o banco é bem modelado, mas o sistema é complexo e o mapeamento é grande…

As suas classes tambem possuem +/- 100 atributos ?? :shock:

Em alguns casos como Cliente sim, depende a tabela mapeada, ja que os dados controlados pelo sistema são muitos obrigatorios

maniacs:

Gerador de dao ?
sim classe mapeada / tabela no banco são mesmos nomes de fields…

Isso, como Skenp, DAO4J, DAOGENERATOR, etc

eles fazem os DAOs e o TOs para você

Bom o primeiro passo foi facil e simples
Adicionar HNDAOFactory
Adicionar HNGenericDAO

Como o controle é feito pela DAOFactory não tive problemas para adicionar o HN
agora vou ao mapeamento…

maniacs:

no meu ver o hibernate em casos como esse, com banco legado não é prodututivo e acaba complicando o desenvolvimento
por isso ainda estou convencido que JDBC é a melhor solução para este caso

emerleite:

maniacs:

no meu ver o hibernate em casos como esse, com banco legado não é prodututivo e acaba complicando o desenvolvimento
por isso ainda estou convencido que JDBC é a melhor solução para este caso

Já considerou o uso de IBatis ? Poderia se uma alternativa interessante. Pelo menos ficar dando setXXX toda hora não vai precisar. O fato é que JDBC na unha somente em casos extremos. Não acho que seja o seu.

Hmmm, uma vez dei uma olhada por cima nele, mais nem me passou em usar ele.
Se não der certo no hibernate eu vejo denovo.

Vlw

A solução que usei foi o Hibernate, graças ao NetBeans e seu mapeamento de classes persistentes
Ele gera todas Entitys, mapeia com Anotations, é apenas carregar o banco nele e mandar gerar
dai foi apagar algumas coisas nas classes e uns xmls que ele gerou e pronto para usar…
mão na roda essa coisas no netbeans

maniacs:

A solução que usei foi o Hibernate, graças ao NetBeans e seu mapeamento de classes persistentes
Ele gera todas Entitys, mapeia com Anotations, é apenas carregar o banco nele e mandar gerar
dai foi apagar algumas coisas nas classes e uns xmls que ele gerou e pronto para usar…
mão na roda essa coisas no netbeans

O hibernate tools no eclipse faria melhor

Bom… eclipse só uso para o superwaba ou como base do Aptana …
oque seria melhor ?

maniacs:

Bom… eclipse só uso para o superwaba ou como base do Aptana …
oque seria melhor ?

A geração de xmls é opcional por exemplo,
alem do mais o HT foi feito pelo pessoal do hibernate… mas eu estava brincando