Bom… estou trabalhando num grupo de pesquisa para a estruturação dos aplicativos que hoje estão na arquitetura client/server ( em C++ ) e passão aos poucos para a web…
Na verdade, essa equipe vai dizer o que usar e como usar…
Já definimos algumas coisas, mas estamos empacando na parte de acesso aos dados…
Já olhei muita coisa: Entity Beans, Hibernate, etc…
Mas gostaria da opinião de vocês para tomar a decisão…
As nossas aplicações trabalham muito forte com SQL hoje…
Quase toda alteração para ganho de performance é feito através dos SQLs…
Para resumir: temos poucas telas de “cadastro” e muita tela com lógica, e boa parte dessa lógica é feita através dos SQLs…
Outro problema é que trabalhamos com dois bancos de dados, então, os SQLs não podem estar fixos como strings dentro das classes…
Não tenho muito tempo para remodelar e padronizar tudo…
Preciso, a principio, fazer as coisas acontecerem de forma rápida mas com um bom nível de qualidade…
O que vcs têm a dizer? Alguém já passou por um problema desse tipo?
Como eu posso resolver o problema dos SQLs??
Não sei se fui claro, mas se faltou alguma informação, me avisem q tentarei explicar de novo…
E se estou postando isso no lugar errado, me desculpem…
Existem diversas estratégias a considerar, e meu primeiro conselho é que procure um bom consultor especializado.
Se isso não for possível (ou mesmo se for, acho que você não vai querer ouvir o que o cara fala sem saber direito das cosias), pense em dividir sua aplicação em módulos funcionais, e ir migrando aos poucos.
Simplesmente substitir programas C++ por programas Java nãodvai te ajudar muito, você precisa definir uma estratégia que crie um ambiente distribuído e em camadas normal.
a gente teve um treinamento conceitual sobre diversas tecnologias java para o desenvolvimento web…
o nosso maior problema é escolher o que utilizar… de forma que eu possa fazer certas coisas que eu já fazia nos aplicativos C++…
não estamos convertendo todos os aplicativos para Java…
estamos começando com pequenas partes…
Mas o problema dos SQLs foi o que mais encomodou até agora…
Hoje, temos uma “DLL” de resources com os sqls…
uma DLL para cada banco…
então, conforme for o banco utilizado, carregamos a DLL e utilizamos o SQL…
mas acredito q esse método seja muito “arcaico”… pois o arquivos com os resources ( SQLs ) fica muito bagunçado… e muito grande…
tudo é feito manualmente sem controle algum…
podemos utilizar uma tecnologia para persistência… e se livrar de alguns SQLs…
mas sei que, na maioria dos casos, eu teria que “driblar” a camada de persistência para consultar os dados de forma mais “poderosa”, usando os vários recursos dos BDs que já utilizo…
acho que vcs são contra isso ( prender a aplicação ao banco )…
eu, de certa forma, também sou…
mas isso ainda é impossível nas nossas aplicações…
alguém teria alguma idéia ou algo que eu deveria ler para tirar as minhas dúvidas?
não posso dizer que tenho experiência “sólida” com objetos, mas, mesmo em C++, utilizava parte dos conceitos de Orientação à Objetos…
bom… vou dar uma lida nesse artigo q vc mandou…
mas, pelo que vi por cima antes de ir almoçar :), os sqls ficarão em arquivos de “.properties”…
acho q a empresa não vai querer q boa parte da logica dela fique visivel aos clientes…
Porque você não usa o DAO pattern.
Você pode encapsular suas SQL em classes.
E pode criar versões das mesmas classes para diversos bancos.
Eu acredito que seja a melhor solução para você.
Você separa o SQL da camada de negócios e ainda utiliza o poder do SQL.
Gostaria de agradeçer a todos os que me ajudaram a resolver o meu problema…
estou utilizando o DAO Pattern e ele se encaixou perfeitamente com aquilo que eu precisava…
so completando,
se vc for usar DAOs como sugerido, pode criar uma factory que conforme o banco conectado, te retorne instancias dos DAOs refentes aquele banco.
ou use preparedStatement e faça sua factory carregar os sql’s de um properties especifico de cada banco.
Usando java 5 e reflection voce pode criar um dao generico que funcione para TODOS os seus objetos, sem ter que mecher um codigo nunca mais. Nao importa o projeto.
Ele esta com duas configuracoes, que da a liberdade pro programador fazer besteira, tem que melhorar um pouco mais:
/**
* Um dao generico usando hibernate (ou alguma ferramenta ORM similar)
*/
class DAO<T> {
private Session session;
public DAO(Session session, Class c) {
this.session = session;
this.clazz = c;
}
public void adiciona(T obj) throws HibernateException {
session.save(obj);
}
public T pesquisaPorId(Long id) throws HibernateException {
return session.load(clazz,id);
}
}
Agora basta usar ele:
DAO<Produto> daoProduto = new DAO<Produto>();
Produto p = new Produto();
// chama os setters aqui
daoProduto.adiciona(p);
DAO<Cliente> daoCliente = new DAO<Cliente>();
Cliente primeiroCliente = daoCliente.pesquisaPorId(1);
Mais avancado: se DAO eh uma interface generica e voce constroi um abstract factory de dao bonitinho, voce consegue quebrar o problema que mencionei do programador fazer besteira.
no meu caso, essas implementações não se encaixam…
eu estou usando o DAO seguindo bem o que o pattern diz…
eu tenho muitas tabelas… dois bancos de dados…
e muito sql cabrero…
