Pessoal, é o seguinte, estou iniciando um novo projeto e decidi desenvolve-lo usando não mais usando o hibernate, e sim uma nova estrutura de apoio na persistencia.
Penso em um arquivo xml contendo as querys, uma classe de gerenciamento dessas querys (acesso as querys previamente carregadas na memoria, talvez usando singleton ou na inicilizacao do sistema ainda nao sei), uma classe de conexao jdbc, uma classe que forneça um pool de conexoes e as classes dao.
Gostaria de saber se alguem de vcs jah trilhou esse caminho e tem alguma dica se seja util.
obs: Eu conheço o tutorial do guj ‘Retirando o SQL do seu código Java’.
[quote=caiozanchetti]Pessoal, é o seguinte, estou iniciando um novo projeto e decidi desenvolve-lo usando não mais usando o hibernate, e sim uma nova estrutura de apoio na persistencia.
Penso em um arquivo xml contendo as querys, uma classe de gerenciamento dessas querys (acesso as querys previamente carregadas na memoria, talvez usando singleton ou na inicilizacao do sistema ainda nao sei), uma classe de conexao jdbc, uma classe que forneça um pool de conexoes e as classes dao.
Gostaria de saber se alguem de vcs jah trilhou esse caminho e tem alguma dica se seja util.
obs: Eu conheço o tutorial do guj ‘Retirando o SQL do seu código Java’.
Obrigado.[/quote]
iBatis
Faz tudo que você quer e mais.
Hibernate faz muito mais do que isso. Não me sinto competente o suficiente para escrever código de caching e lazy/eager-load. Se você só precisa de algo para facilitar com as queries, realmente não é necessário.
Existem projetos onde os dados são orietados a objeto, e existe outros que não. E se no seu caso o projeto não vai utilizar dados orietados a objeto, utilize o iBatis.
Mas não tente fazer um projeto aonde seus dados são orietados a objetos com o iBatis, até é possivel, mas nesse caso o Hibernate seria a melhor opção.
Comecei a ler o tópico e pensei “Mas pq esse cara não quer usar Hibernate?” :D, ai pensei melhor e vi que eu nao domino o JDBC, sempre utilizei camadas de persistência e não conheco os macetes de JDBC, seria uma boa fazer algo na unha assim. Mas ai pensei um pouco mais, e se eu quiser fazer tudo na unha, vou fazer minha própria implementação de Collection para utilizar ao invés de LinkedList? vou implementar um leitor de XML ao invés de usar o Digester? Vou implementar um fórum ao invés de utilizar o GUJ?
Cara, não há nada de mal em usar camadas de persistência, aliás o que vai ser cobrado de vc nos projeto que particiapar é o conhecimento profundo em camadas de persistência que aumentam e muito a produtividade, se está insatisfeito com Hibernate, ótimo, isso é muito bom mesmo, tente usar outras camadas de persistência, mas não ande pra trás tentando reinventar a roda, essas camadas de persistência são projetos longos e complexos, muito bem testados.
Garanto que se vc chegar em uma empresa vai contar muito mais ponto pra vc dizer que sabe utilizar 3 ou 4 camadas de persistência ao invés de dizer que sabe JDBC.
Bem, alguns frameworks de persistência tiram um pouco do poder do sql, além de serem complicadas de utilizar quando se utiliza uma base cheia de inconsistências que devem ser resolvidas na unha. Eu acho sempre bom ter o domínio do JDBC puro mesmo. Nesses casos não se trata de reinventar a roda.
Uma coisa é ter domínio de SQL e JDBC, outra é utilizar um framework que abstrai 90% do trabalho chato e repetitivo que é converter objetos em tabelas. Um não exclui o outro.
Eu concordo com você pcalcado. Foi isso mesmo que eu quis dizer. O ideal é usar um framework sempre que possível, mas quis levantar a questão de que às vezes é difícil de utilizar frameworks. Trabalhei com uma base de dados que não utilizava chaves estrangeiras e tinha duas tabelas representando (quase) a mesma informação de clientes. Os dados eram replicados e validados nas duas tabelas na unha. Claro, o problema era a base, mal formulada, mas já estava em funcionamento e não poderia mudar. Não consigo imaginar um código que se utilize de algum framework e consiga tratar bem essas dificuldades para a referida base. Se for possível (e de forma simples) me respondam como hehe
