Cara, acho que vc ainda pode tirar proveito do iBatis. Vou tentar com o exemplo de código que vc mandou (estilo call exec).
Posto aqui e depois vc vê se te atende ou se vc gosta.
Até o final da madruga eu posto algo aqui (positivo ou negativo).
[quote] O iBatis ajuda exatamente nisso. Todos seus sqls ficarão em arquivos XMLs simples. Vc ainda terá uma camada de persistência (DAO) mas sua camada não fala jdbc. Ela simplismente delega isso pro ibatis.[/quote]Vc, ira usar Spring DAO.
http://blog.empas.com/ahnyounghoe/read.html?a=13432899&c=1130709
http://diesil-java.blogspot.com/2006_06_01_archive.html
http://ibatis.apache.org/javadownloads.cgi
sds.
[quote=WilliamSilva][quote] O iBatis ajuda exatamente nisso. Todos seus sqls ficarão em arquivos XMLs simples. Vc ainda terá uma camada de persistência (DAO) mas sua camada não fala jdbc. Ela simplismente delega isso pro ibatis.[/quote]Vc, ira usar Spring DAO.
http://blog.empas.com/ahnyounghoe/read.html?a=13432899&c=1130709
http://diesil-java.blogspot.com/2006_06_01_archive.html
http://ibatis.apache.org/javadownloads.cgi
sds.[/quote]
Verdade, o iBatisDAO foi descontinuado por ser redundante. O iBatisDAO é uma outra bibilioteca que ficava acima do sqlMaps que mencionei. O iBatis é hoje apenas o sqlMap. Pelo que lembro o iBatisDAO era nada mais nada menos que o quê o spring faz com os templates de DAO, daí então a galera do iBatis achou melhor descontinuar.
O exemplo de código que postei (código de produção) usa apenas o ibatis.
Nunca usei o iBatis com o spring. Mas fico meio ressabiado só de pensar numa aplicação orientada à banco com ioc.
Quando disse camada DAO tinha em mente uma camada DAO java mesmo (vide código).
[quote] Nunca usei o iBatis com o spring. Mas fico meio ressabiado só de pensar numa aplicação orientada à banco com ioc. [/quote]Pode explicar pq. vc. ficaria ressabiado por usar o spring Dao "“org.springframework.orm.ibatis.SqlMapClientFactoryBean”, Ele continua sendo um DAO : http://www.springframework.org/docs/reference/orm.html
http://www.oreilly.com/catalog/springadn/excerpt/springadn_ch05_81-90.pdf
A próxima versão do iBATIS prevê o uso de POJOs e annotations.
Mais pode-se usar somente "iBATIS SQL Maps " e para melhorar o desempenho o OSCache.:
http://www.onjava.com/pub/a/onjava/2005/02/02/sqlmaps.html?page=1
(Ps. qualquer semelhança desse artigo SQLMaps c/ a publicação de mesmo título em uma revista brasileira não é conhecidência é plagio e tradução não autorizada.)
http://www.opensymphony.com/oscache/
[quote=WilliamSilva]Pode explicar pq. vc. ficaria ressabiado por usar o spring Dao[/quote]Pode ser bobeira minha, tento sempre partir pro mais simples quando se trata de trabalhar com aplicações orientadas à banco, essas velharias sempre me pegam desprevinido. Me sinto como se estivesse tentando socar um triângulo dentro de um quadrado …
Olha só o caso desse post, tô pensando até em abrir outro post só pra ver a opinião da galera sobre esse lance de atualizar sequence dentro de trigger e tal …
Tem tudo a ver com minha assinatura não tem não?
Me pergunto o seguinte: pra quê que eu preciso de uma factory de beans para uma camada DAO que está usando iBatis? Mesmo no caso simples de utilizar um DAO Factory com iBatis, na minha opinião, isso já seria redundante. Teria de criar interfaces para DAOs que não teriam variação de código simplesmente porque a porção que poderia vir a variar (os sqls em si) já está fora desses DAOs.
Dependendo da abordagem isso é uma discussão sem fim.:
Começando com o modelo de SGBDs Relacionais, que tem um monte de DBAs que ainda vivem de querer re-inventar a roda com "tabelas normalizadas na 1º, 2º, 3º Normal Form e esquecem que há mais Formas, e depois que ficarem perdidos com tantos MERs errados (raros conhecem Modelo de dominio) ijá que existe a desnormalização vamos usar e,isso vem acontecendo muito ultimamente e, é interessante principalmentequando vc. revê alguns conceitos “acadêmicos” ( nunca levei a sério algumas colocações que me foram passadas na Universidade- pelos professores) quando lê um artigo assim " http://blog.fragmental.com.br/2006/08/24/bases-de-dados-sao-recursos/ " , e ai vc. começa a ver que existem mais coisas que alguns DBAs deveriam olhar com mais atenção, alguns links abaixo expressam a sua observação porèm devo dizer que hà controversias e como vc, disse é assunto para um outro post.
http://blog.michaelnascimento.com.br/2006/08/30/vale-a-pena-abstrair/
http://blog.michaelnascimento.com.br/2006/09/22/vale-a-pena-abstrair-parte-2/
http://blog.caelum.com.br/2006/08/26/ei-como-e-o-seu-dao-ele-e-tao-abstraido-quanto-o-meu/
http://blog.caelum.com.br/2006/12/17/design-patterns-um-mau-sinal/
sds.
[quote=WilliamSilva]Dependendo da abordagem isso é uma discussão sem fim.[/quote]Seria tão mais fácil se tudo nessa área fosse ou preto ou branco não acha?
Vou dar uma olhada no material que vc linkou, mas te adianto que, na minha opinião, nem sempre vale a pena abstrair bases legadas para um novo sistema oo. Sei que isso é uma simplificação absurda mas na correria do dia a dia é o que eu acabo fazendo.
Agora te pergunto: vc acha que sempre vale a pena usar essa abordagem quando estamos desenvolvendo um novo sistema com uma base legada? uma base que vc não pode alterar ?
Obrigado pelos links …
ainda estou devendo o exemplo com a trigger no iBatis …