Diversas dúvidas sobre estruturação de app

Olá, Fábio,

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.

[]s

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?

Bom, para manter o uso de SQL, você pdoe seguir as dicas deste artigo.

Num próximo passo, você pdoe estudar o Hibernate.

Vocês tem experiência sólida com objetos?

[]s

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.

Olá

Dei 5 estrelas por este sábio conselho.

[]s
Luca

blz…
vou dar uma olhada na especificação do DAO Pattern para ver se atende às minhas necessidades…

obrigado…

Luca:

Olá

Dei 5 estrelas por este sábio conselho.

[]s
Luca

com certeza seria uma ótima solução…
mas falta $$$ pra isso… hehehhe

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…

Obrigado pelas dicas…

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.

[]'s

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.

Impressionante, nao?

Eu tô começando a mexer com o Tiger e tô gostando muito, mas Guilherme, dah para dar uma palhinha para nós desse superDAO?

1. A versao sem Java 5 eh soh tirar o generics.
2. 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.

E para quem continua usando JDBC, tem uma serie de artigos no javalobby de como utilizar sabiamente o mesmo. Otimizacao etc.

Dicas como: quando nao usar preparedstatement pq ele eh muito lento em alguns casos. Que tal? Dessa todo mundo se assusta.

Abraco

Guilherme

Guilherme…

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…

mas mesmo assim, valeu pelas dicas…