Nota Fiscal Paulista em Swing e Migração de JDBC p/ Hibernate

Sobre a nota fiscal eletrônica não posso dizer muita coisa. Mas sobre o hibernate, você já considerou utilizar uma API mais simples, e mais integrada ao banco de dados, como o IBatis?

Racional:

1. Você realmente pretende mudar de sistema gerenciador de banco de dados com freqüência, ou deixar isto totalmente aberto para uma gama grande de clientes? Se sim, hibernate pode ser interessante. Se não, o IBatis é bom.

2. Se você quiser escovar a performance do banco de dados, a flexibilidade de banco não é muito legal, porque as soluções aplicadas para performance em um banco de dados podem não se aplicar a outros.

3. Você vai criar o banco de dados do zero? Se sim, o hibernate é interessante porque você cria as entidades em java e ele transforma estas entidades em banco de dados. Se não, o IBatis resolve bem o problema.

Minha experiência de 2007 e 2008 com o hibernate é que há muitas “pegadinhas” para implantação, que podem atrapalhar bastante uma manutenção. Relacionamentos um-para-muitos, a questão de se usar lazy initializers ou não, tudo isso pode ser bastante aborrecido.
Não minha opinião, válida para o hibernate láaa de 2007, não há um bom diálogo entre o Hibernate e DBAs, porque as operações SQL que o hibernate faz ficam todas escondidas em logs da aplicação. No IBatis, as operações SQL estão à vista no próprio código fonte.

Bom sobre Hibernate como naum tenho vasta experiencia (so estou no meu primeiro sistema) estou adorando o mesmo, mas gostei das dicas do abmpicoli sobre iBates vou pesquisar…

abmpicoli:

Sobre a nota fiscal eletrônica não posso dizer muita coisa. Mas sobre o hibernate, você já considerou utilizar uma API mais simples, e mais integrada ao banco de dados, como o IBatis?

Racional:

1. Você realmente pretende mudar de sistema gerenciador de banco de dados com freqüência, ou deixar isto totalmente aberto para uma gama grande de clientes? Se sim, hibernate pode ser interessante. Se não, o IBatis é bom.

2. Se você quiser escovar a performance do banco de dados, a flexibilidade de banco não é muito legal, porque as soluções aplicadas para performance em um banco de dados podem não se aplicar a outros.

3. Você vai criar o banco de dados do zero? Se sim, o hibernate é interessante porque você cria as entidades em java e ele transforma estas entidades em banco de dados. Se não, o IBatis resolve bem o problema.

Minha experiência de 2007 e 2008 com o hibernate é que há muitas “pegadinhas” para implantação, que podem atrapalhar bastante uma manutenção. Relacionamentos um-para-muitos, a questão de se usar lazy initializers ou não, tudo isso pode ser bastante aborrecido.
Não minha opinião, válida para o hibernate láaa de 2007, não há um bom diálogo entre o Hibernate e DBAs, porque as operações SQL que o hibernate faz ficam todas escondidas em logs da aplicação. No IBatis, as operações SQL estão à vista no próprio código fonte.

De fato, o Hibernate não é lá tão flexível em relação ao banco… ele tem uma série de restrições e pontos que você deve considerar:

1. Você usa stored procedures (ou algo do gênero)? Se usar, descarte Hibernate.

2. Seu banco é normalizado? Se não for, descarte Hibernate.

3. Você tem muitas chaves compostas? Se tiver, olhe com atenção esse ponto, porque cada chave composta é, para o Hibernate, uma classe nova. Fica muito chato de gerenciar uma aplicação com várias classes só de chaves compostas.

4. Suas consultas JDBC têm muitos joins? Se tiver, cuidado com o Hibernate, porque, como o abmpicoli citou, você terá que saber muito bem como gerenciar a questão de lazy initialization. Além do que, o Hibernate não tem o conceito de lazy initialization “seletiva”, isto é, inicializar somente alguns objetos em um relacionamento many-to-one, por exemplo. Se você pedir uma coleção em um objeto, ele vai trazer TODOS os objetos daquela coleção, e não alguns selecionados.

Pra concluir… o Hibernate e o JDBC não costumam ser muito semelhantes. O ideal é que se comece um projeto com o Hibernate e, como não foi seu caso, é plausível utilizar alguns design patterns antes de pensar na transição. Como já foi falado, considere usar também o iBatis antes, ou mesmo algum outro framework ORM que atenda às restrições que passei (não conheço nenhum ).

[]'s

Sobre o Ibatis :

Para quem não conhecia assim como eu …

O que é iBatis ?

Um framework JDBC
O desenvolvedor escreve o código SQL, e o iBATIS executa usando JDBC.
Não precisa de try/catch/finally/try/catch.
Mapeador SQL
Automaticamente mapeia as propriedades dos objetos com parâmetros da query SQL.
Automaticamente mapeia os resultados da query com os objetos.
Tem suporte ao problema das queries com relacionamento N+1.
Gerente de transações
iBATIS fornece o gerenciamento de transactions para operações no banco de dados se não houver outro gerenciador disponível .
IBATIS usará outro gerenciador de transactions se disponível (Spring, EJB CMT, etc.).
Ótima integração com Spring, mas também pode ser usado sem o Spring (o Spring foi um dos primeiros frameworks a dar suporte ao iBATIS).
O que o iBATIS não é ?

Um ORM
Não gera SQL
Não tem uma linguagem propretária
Não sabe sobre a identidade do objeto
Não faz persistência de objetos automaticamente
Não faz cache de objetos
url[/url]

abmpicoli :
Você realmente pretende mudar de sistema gerenciador de banco de dados com freqüência, ou deixar isto totalmente aberto para uma gama grande de clientes? Se sim, hibernate pode ser interessante

Não , tenho certeza absoluta que meu software ia ter que crescer muito para cansar um PostgreSQL por exemplo .

Achei 3 Artigos que a Loiane nossa amiga aqui do GUJ escreveu e por sinal são de muito boa qualidade:

Introdução ao iBatis (MyBatis), uma alternativa ao JDBC e Hibernate
http://www.loiane.com/2011/02/introducao-ao-ibatis-mybatis-uma-alternativa-ao-jdbc-e-hibernate/

Começando com iBatis (MyBatis): Annotations
http://www.loiane.com/2011/02/comecando-com-ibatis-mybatis-annotations/

Começando com iBatis (MyBatis): Configuração em XML
http://www.loiane.com/2011/02/comecando-com-ibatis-mybatis-configuracao-em-xml/

Irei pensar , acho que este framework , vai cair como uma luva , pois vou me livrar das configurações , Connection e tuda aquela bagunça que esta junto com todas as consultas do sistema :twisted:

me digam os amigos, prum primeiro sistema, meu caso, valeria a pena trocar o Hibernate pelo iBates tenho uma 10 tabelas? pq o ingraçado q nunca ouvi falar nele.

Obrigado asaudate e abmpicoli

Pelo que vi vai dar muitooo trampo utilizar o Hibernate , pois como nosso amigo asaudate disse os relacionamentos seriam um grande problema , e não to muito afim de modificar as minhas classes modelo por enquanto , quero arrumar a camada de persistência e manter o sistema funcionando.
Oque acontece é o seguinte , estou planejando expandir algumas funcionalidades do sistema , mais continuar encima da bagunça vai virando uma bola de gato e vai chegar um dia que terei muitos problemas , por isso vejo que a vantagem é organizar e arrumar oque tem que ser arrumado agora.

Cara , este é um assunto que sou completamente leigo , como posso utilizar design patterns para melhorar a arquitetura do meu sistema de forma efetiva e pratica ?

Oque eu pretendo fazer é separar as classes utilizando-se de MVC e conseguir um baixo acoplamento entre minhas classes de persistência .
Pois da Maneira que esta ao persistir Funcionario por exemplo eu tenho acesso total ao metodo persisteProduto e n coisas mais que tenho até medo de falar :shock: .

E Sobre a NTPaulista + Swing … Ninguém implementou em algum sistema ou ja viu um exemplo?

mausexdd:

Obrigado asaudate e abmpicoli

Pelo que vi vai dar muitooo trampo utilizar o Hibernate , pois como nosso amigo asaudate disse os relacionamentos seriam um grande problema , e não to muito afim de modificar as minhas classes modelo por enquanto , quero arrumar a camada de persistência e manter o sistema funcionando.
Oque acontece é o seguinte , estou planejando expandir algumas funcionalidades do sistema , mais continuar encima da bagunça vai virando uma bola de gato e vai chegar um dia que terei muitos problemas , por isso vejo que a vantagem é organizar e arrumar oque tem que ser arrumado agora.

Cara , este é um assunto que sou completamente leigo , como posso utilizar design patterns para melhorar a arquitetura do meu sistema de forma efetiva e pratica ?

Oque eu pretendo fazer é separar as classes utilizando-se de MVC e conseguir um baixo acoplamento entre minhas classes de persistência .
Pois da Maneira que esta ao persistir Funcionario por exemplo eu tenho acesso total ao metodo persisteProduto e n coisas mais que tenho até medo de falar :shock: .

Comece dando uma olhada no padrão DAO (Data Access Object). É um padrão específico para esse tipo de coisa: abstrair esse tipo de lógica do resto da aplicação. Considere criar uma classe abstrata (GenericDAO, por exemplo). Depois, estenda essa classe para algo um pouco mais específico (JDBCDAO, por exemplo). Essa classe, no caso do seu JDBC, vai conter alguns templates de métodos que são usados em todos os DAO’s JDBC, como abrir conexão, fechar, recuperar resultados de ResultSet, e por aí vai. Deixe essa classe o mais flexível possível para que não seja necessário fazer muito quando você estender ela também (o DAO JDBC deve ser abstrato também). Depois, você faz uma estensão dessa classe por classe de modelo, implementado somente coisas específicas que sejam necessárias por cada classe de modelo.

Depois, ao invés de referenciar diretamente os DAO’s de cada classe de modelo, crie interfaces para eles e referencie essas interfaces, de maneira que você não precise saber que está usando nem um GenericDAO, nem um um JDBC DAO nem nada assim, somente as interfaces do modelo. Assim, quando você substituir o JDBCDAO por um iBatisDAO da vida, você não vai precisar mexer em mais nada.

Se o sistema for muito grande, você pode considerar usar TemplateMethod ou mesmo AbstractFactory para fazer a instância dessas classes. Caso contrário, não é necessário, você muda a maneira de instanciar diretamente nas classes.

Se for interessante, também, você pode usar uma abordagem voltada para o DDD e criar repositórios para cada objeto. Vale lembrar que um Repositório não é um DAO; é um objeto mais voltado para a camada de negócios da aplicação, mas sabe fazer persistência. Ou seja, ele pode conter regras de negócio tranquilamente, porque ele faz parte do domínio da aplicação.

E, por último, mas não menos importante: utilize injeção de dependências, sempre! Não importa se você usa um framework pra isso ou não, mas sempre forneça aos objetos aquilo de que eles vão precisar, nunca faça o lookup diretamente. Isso porque você vai precisar testar essas classes, e testar persistência sem injeção de dependências é praticamente impossível.

Enfim… eu sei que é bastante informação, mas o fórum está aqui sempre que você precisar, OK?

[]'s

Acho que aqui cabe a seguinte pergunta:

Quando você pensa em um sistema você pensa primeiro nas tabelas ou primeiro nas classes?

Se você pensa primeiro nas tabelas, você precisa apenas em uma ferramenta que preencha facilmente objetos ada uma consulta SQL, ou que popule um insert com base em dados de um objeto. IBatis é jóia pra isso.

Se você tem que ter mais flexibilidade de implantação, está criando um banco de dados do zero, ou faz a modelagem de objetos para depois pensar no banco, talvez o hibernate seja melhor para você, porque ele pode gerar todos os create tables, e etc.

Porém, no hibernate quando se pensa em fazer uma aplicação que vai ter que ser mantida, você sempre vai precisar trabalhar com duas linguagens: SQL do banco de dados e SQL do hibernate. Isso porque se um query ficar lerdo, por exemplo, você vai ter que ver o que c. que o hibernate tá fazendo como query e depois ver como você vai fazer um “SQL” hibernate que faça um query melhor, ou vai mudar a configuração do mapeamento objeto-relacional.

Essa é minha opinião. Nota: falando em IBatis de 2012 contra hibernate de 2007. Não sei se houve alguma mudança significativa em ambos frameworks.

:-o

Isso aqui era oque eu tinha em mente , até pensava em algo menos eficiente , teria um DAO para cada modelo , ProdutoDAO , PessoaDAO , mas como voce citou é bom fazer alguns templates de métodos em uma classe genérica pois alguns métodos serão teoricamente repetitivos.

Essa parte não peguei direito… e IOC estou estudando tbm …

Vou começar com oque você sugeriu , e conforme for surgindo as dúvidas vou atualizando aqui.

Voce teria em algum repositório Git ou outro , algum exemplo de persistência neste padrão de design patterns com IOC?

vlw t+

mausexdd:

:-o

Isso aqui era oque eu tinha em mente , até pensava em algo menos eficiente , teria um DAO para cada modelo , ProdutoDAO , PessoaDAO , mas como voce citou é bom fazer alguns templates de métodos em uma classe genérica pois alguns métodos serão teoricamente repetitivos.

Essa parte não peguei direito… e IOC estou estudando tbm …

Vou começar com oque você sugeriu , e conforme for surgindo as dúvidas vou atualizando aqui.

Voce teria em algum repositório Git ou outro , algum exemplo de persistência neste padrão de design patterns com IOC?

vlw t+

Seria interessante você ter uma interface, digamos, para Pessoa, mais ou menos assim:

public interface PessoaDAO {

public Pessoa recuperarPessoaPorNome(String nome) throws PessoaNaoEncontradaException;

public Collection<Pessoa> listarTodos();

public Pessoa recuperarPessoa (Long id) throws PessoaNaoEncontradaException;

}

O que, aliás, é mais parecido com um repositório do que com um DAO =)

Na minha assinatura tem um link pra um quickstart com Spring, Jersey, etc. e etc. Não é exatamente o que você precisa, mas a parte de acesso a dados exemplifica um pouco a parte de injeção de dependências (com setters).

[]'s

Acho que aqui cabe a seguinte pergunta:

Quando você pensa em um sistema você pensa primeiro nas tabelas ou primeiro nas classes?

Se você pensa primeiro nas tabelas, você precisa apenas em uma ferramenta que preencha facilmente objetos ada uma consulta SQL, ou que popule um insert com base em dados de um objeto. IBatis é jóia pra isso.

Se você tem que ter mais flexibilidade de implantação, está criando um banco de dados do zero, ou faz a modelagem de objetos para depois pensar no banco, talvez o hibernate seja melhor para você, porque ele pode gerar todos os create tables, e etc.

Porém, no hibernate quando se pensa em fazer uma aplicação que vai ter que ser mantida, você sempre vai precisar trabalhar com duas linguagens: SQL do banco de dados e SQL do hibernate. Isso porque se um query ficar lerdo, por exemplo, você vai ter que ver o que c. que o hibernate tá fazendo como query e depois ver como você vai fazer um “SQL” hibernate que faça um query melhor, ou vai mudar a configuração do mapeamento objeto-relacional.

Essa é minha opinião. Nota: falando em IBatis de 2012 contra hibernate de 2007. Não sei se houve alguma mudança significativa em ambos frameworks.

abmpicoli vamos como fiz, criei as tabelas e só depois crias as classes, ou seja, iBatis é o ideal?

luxu

se eu fosse você , faria igual o amigo acima aconselhou , definir primeiramente a arquitetura de persistência corretamente e só depois implementar o framework.

Implementar o framework , sera o menor dos problemas que nós iremos ter …

asaudate

de uma olhada aqui por favor
http://www.loiane.com/2011/02/comecando-com-ibatis-mybatis-configuracao-em-xml/

Este tutorial da loiane com o framework IBatis , basicamente não cobre oque você me aconselhou ?

Pensei basicamente isto:
1 ? Contact POJO - modelo
2 - Contact.xml - seria a parte especifica só meus SQL
3 ? Arquivo de Configuração ? Mapper seria a configuração do meu BD
4 -MyBatisConnectionFactory - seria minhas conexoes
5 - ContactDAO que seria o meu DAO especifico.

Isto segue os padrões que voce citou , e como insiro IOC desta maneira?

mausexdd:

asaudate

de uma olhada aqui por favor
http://www.loiane.com/2011/02/comecando-com-ibatis-mybatis-configuracao-em-xml/

Este tutorial da loiane com o framework IBatis , basicamente não cobre oque você me aconselhou ?

Pensei basicamente isto:
1 ? Contact POJO - modelo
2 - Contact.xml - seria a parte especifica só meus SQL
3 ? Arquivo de Configuração ? Mapper seria a configuração do meu BD
4 -MyBatisConnectionFactory - seria minhas conexoes
5 - ContactDAO que seria o meu DAO especifico.

Isto segue os padrões que voce citou , e como insiro IOC desta maneira?

É por aí, sim. Mas perceba que o ContactDAO do tutorial dela é orientado ao iBatis. Seria interessante que você abstraísse esse ContactDAO para não ser amarrado ao iBatis e, mesmo assim, olhe essa linha:

public ContactDAO(){
        sqlSessionFactory = MyBatisConnectionFactory.getSqlSessionFactory();
    }

A versão “injeção de dependências” seria assim:

public ContactDAO(SQLSessionFactory sqlSessionFactory ) {
 this.sqlSessionFactory  = sqlSessionFactory ;
}


//Em outro trecho..

new ContactDAO(MyBatisConnectionFactory.getSqlSessionFactory());

Perceba que a implementação de ContactDAO, aqui, é dependente do iBatis. Criando uma interface que abstraia os métodos, você não fica amarrado à implementação, sendo livre para trocar o framework de persistência.

Boa , vou seguir esta linha de raciocínio, tentando desvincular o máximo com o framework e vou postando os códigos aqui.

Sobre a NFP , eu estive pesquisando e vi que irei ter que criar uma web-service , da para integrar isso com Swing?
e alguém conhece algum tutorial de web-service para NFP? achei que seria uma coisa mais simples…

Vou abrir outro tópico para NFP.

mausexdd:

Sobre a NFP , eu estive pesquisando e vi que irei ter que criar uma web-service , da para integrar isso com Swing?
e alguém conhece algum tutorial de web-service para NFP? achei que seria uma coisa mais simples…

Você não precisa criar o web service, só o cliente dele.

Quanto a como criar esse cliente, tem vários (vários mesmo!) tópicos aqui no GUJ sobre isso. Dê uma pesquisada, um dos tópicos tem mais de quarenta páginas.

[]'s

Acho que aqui cabe a seguinte pergunta:

Quando você pensa em um sistema você pensa primeiro nas tabelas ou primeiro nas classes?

Se você pensa primeiro nas tabelas, você precisa apenas em uma ferramenta que preencha facilmente objetos ada uma consulta SQL, ou que popule um insert com base em dados de um objeto. IBatis é jóia pra isso.

Se você tem que ter mais flexibilidade de implantação, está criando um banco de dados do zero, ou faz a modelagem de objetos para depois pensar no banco, talvez o hibernate seja melhor para você, porque ele pode gerar todos os create tables, e etc.

Porém, no hibernate quando se pensa em fazer uma aplicação que vai ter que ser mantida, você sempre vai precisar trabalhar com duas linguagens: SQL do banco de dados e SQL do hibernate. Isso porque se um query ficar lerdo, por exemplo, você vai ter que ver o que c. que o hibernate tá fazendo como query e depois ver como você vai fazer um “SQL” hibernate que faça um query melhor, ou vai mudar a configuração do mapeamento objeto-relacional.

Essa é minha opinião. Nota: falando em IBatis de 2012 contra hibernate de 2007. Não sei se houve alguma mudança significativa em ambos frameworks.

abmpicoli vamos como fiz, criei as tabelas e só depois crias as classes, ou seja, iBatis é o ideal?

Cara, não existem respostas simples para isso… Mas, olhando bem por alto o que me parece que você está fazendo ou quer fazer, acho que IBatis é uma boa opção.

Eu vejo hibernate como uma opção legal para a seguinte situação: você está implantando uma solução comercial, que deverá ser instalada em vários servidores diferentes, em clientes diferentes, com servidores de banco de dados diferentes. Nesse caso, hibernate é uma solução boa, porque a princípio você vai ter a quintessência do que é o java implantado na sua aplicação. Sem praticamente nenhuma alteração, somente arquivos de configuração, você irá conseguir implantar sua solução em todos estes servidores. Além disto, não precisará manter as DDLs de criação do banco de dados.

Acho que aqui cabe a seguinte pergunta:

Quando você pensa em um sistema você pensa primeiro nas tabelas ou primeiro nas classes?

Se você pensa primeiro nas tabelas, você precisa apenas em uma ferramenta que preencha facilmente objetos ada uma consulta SQL, ou que popule um insert com base em dados de um objeto. IBatis é jóia pra isso.

Se você tem que ter mais flexibilidade de implantação, está criando um banco de dados do zero, ou faz a modelagem de objetos para depois pensar no banco, talvez o hibernate seja melhor para você, porque ele pode gerar todos os create tables, e etc.

Porém, no hibernate quando se pensa em fazer uma aplicação que vai ter que ser mantida, você sempre vai precisar trabalhar com duas linguagens: SQL do banco de dados e SQL do hibernate. Isso porque se um query ficar lerdo, por exemplo, você vai ter que ver o que c. que o hibernate tá fazendo como query e depois ver como você vai fazer um “SQL” hibernate que faça um query melhor, ou vai mudar a configuração do mapeamento objeto-relacional.

Essa é minha opinião. Nota: falando em IBatis de 2012 contra hibernate de 2007. Não sei se houve alguma mudança significativa em ambos frameworks.

abmpicoli vamos como fiz, criei as tabelas e só depois crias as classes, ou seja, iBatis é o ideal?

Cara, não existem respostas simples para isso… Mas, olhando bem por alto o que me parece que você está fazendo ou quer fazer, acho que IBatis é uma boa opção.

Eu vejo hibernate como uma opção legal para a seguinte situação: você está implantando uma solução comercial, que deverá ser instalada em vários servidores diferentes, em clientes diferentes, com servidores de banco de dados diferentes. Nesse caso, hibernate é uma solução boa, porque a princípio você vai ter a quintessência do que é o java implantado na sua aplicação. Sem praticamente nenhuma alteração, somente arquivos de configuração, você irá conseguir implantar sua solução em todos estes servidores. Além disto, não precisará manter as DDLs de criação do banco de dados.

Em compensação, vale lembrar que o Hibernate tem uma vantagem (enorme) em cima do iBatis, que é o cache de objetos/queries. Aliando-se a isso um provedor bom de cache, como o Memcached, e o Hibernate passa a ser praticamente imprescindível numa aplicação.

[]'s

asaudate:

…
Em compensação, vale lembrar que o Hibernate tem uma vantagem (enorme) em cima do iBatis, que é o cache de objetos/queries. Aliando-se a isso um provedor bom de cache, como o Memcached, e o Hibernate passa a ser praticamente imprescindível numa aplicação.

[]'s

Quanto ao cache de objetos: vamos confirmar o conceito - é a capacidade do hibernate de armazenar os objetos recuperados do banco na memória da máquina Java e, nas consultas seguintes a estes objetos, recuperá-los diretamente da máquina, ao invés de efetuar uma nova consulta ao banco.
Concordo, é uma característica interessante do Hibernate. Se você tem uma única aplicação se utilizando do banco de dados. Porém, não existem respostas simples em Engenharia de Software, não é mesmo? Se você tiver duas aplicações se utilizando de duas tecnologias distintas, por exemplo, uma aplicação legada e um front-end novo, o cache se torna mais um problema do que uma solução, pois informações obsoletas podem ficar presentes no cache com mais freqüência. Em uma empresa que trabalhei eles desativaram os caches da aplicação justamente por haver este tipo de problema. É verdade que o Memcache minimizaria este problema, mas não seria possível aplicar o memcache na aplicação legada…

Quanto ao cache de queries: é a capacidade do hibernate de armazenar as chaves primárias de uma consulta, de forma que numa consulta posterior estas mesmas chaves são recuperadas, sem acessar o banco.

Em resumo, caches são bons, na minha opinião, para tabelas que são muito acessadas e raramente modificadas, e cuja informação contida seja de natureza não crítica. Exemplos: parâmetros de configuração da aplicação; Lista dos estados da união; Municípios do País.

Em resumo, nessa “briga” entre IBatis e Hibernate, não há vencedores nem perdedores.
O Hibernate acrescenta uma camada extra na aplicação, que tem “vontade própria” mas, se bem configurada, confere melhorias de performance da aplicação pelos tais caches mencionados e pode simplificar a codificação, especialmente se são criados muitos queries diferentes para poucas tabelas, o que dilui o custo extra da configuração destas tabelas no hibernate. Esta mesma camada extra, por outro lado, pode gerar problemas que podem deixar o mantenedor maluco para resolvê-los, como a questão do cache mencionado acima.

O IBatis não melhora nem minimiza o acesso a banco, apenas facilita na manipulação das queries e updates do banco. Tem muito pouca configuração envolvida. O desenvolvedor tem mais controle sobre como as operações de banco são feitas. Isto é ao mesmo tempo uma bênção e uma maldição: por exemplo, o mapeamento de uma consulta a objetos pode ser feita de forma inconsistente quando vários programadores estão trabalhando no código, o que pode gerar problemas de diagnóstico difícil. Mas é melhor que usar JDBC diretamente.