Armadilhas e práticas Casos de Uso: Toplink, Hibernate, Eclipse link, Ibatis

Question

Eu trabalhei muito com Hibernate como minha implementação JPA. Na maioria dos casos ele funciona muito bem! Mas também tenho visto um monte de armadilhas:

• Remoting com objetos persistentes é difícil, porque Hibernate substitui as coleções Java com sua própria implementação coleção. Assim, a cada cliente deve ter o Hibernate .jar bibliotecas. Você tem que tomar cuidado sobre exceções LazyLoading etc. Uma maneira de contornar este problema é o uso de webservices.
• verificação sujo é feito no banco de dados sem qualquer bloqueio.
• "SQL atrasada", faz com que o acesso a dados não é compatível com ACID. (Perda de dados ...)
• Implict Atualizações >> Então não sabemos se um objeto é modificado ou não (commit atualizações causas).

Existem problemas semelhantes com Toplink, Eclipse Link e Ibatis? Quando devo usá-los? Eles têm um desempenho semelhante? Existem razões para escolher Eclipse ligação / Toplink ... sobre Hibernate?

Answer 1

eu posso compartilhar minha boa quantidade de armadilhas do Hibernate:

• Criteria API não é typesafe
• Criteria API é relativamente ruim projetado (ex: você não pode recuperar os aliases atuais)
• Se você criar um alias, você está forçando participar de um interno (isto é nos docs, mas é enganosa)
• Não há suporte para UNIONs
• Não há forma fácil de ' de-proxy ' um objeto persistente (remoting é suportada por terceiros)
• Não há suporte para tabelas sem PKs (I agora é idiota, mas isso acontece em sistemas legados)
• Não há forma fácil de usar seqüências de colunas não-PK (não tão mudo)

Como para a maioria das implementações de JPA, eu sempre achei que eu teria que contar com algumas anotações personalizadas ou então para fazer coisas que não é coberto na especificação JPA.

Answer 2

Existem razões para escolher Eclipse Link / Toplink ... sobre Hibernate?

Em O / R terra desenvolvedor mapeador (onde moro;)) é um fato comum que Toplink é considerado o mais completo de recursos e melhor O / R mapper lá fora. Ele tem suas fraquezas, mas seu vasto número de características torna algo que é difícil de bater. Como agora é open source e gratuito, que eu lhe daria uma tentativa.

iBatis não é realmente um mapeador O / R, é mais de um enchimento de classe / persister através de SQL embutido. Então você tem que fazer o trabalho pesado e tem que escrever todas as consultas. iBatis é útil quando você está usando um banco de dados com procedimentos armazenados e ter de utilizar esses procs para DML / recuperação set.

Answer 3

Não posso comentar sobre outras implementações mas para DataNucleus AccessPlatform ...

1. Remoting pode exigir "jdo.jar" para estar presente desde as classes de modelo são bytecode reforçada. Alternativamente, se usado "read-only" do lado remoto, em seguida, usar as classes un-reforçado lá e todos os trabalhos, sem a jar adicional.
verificação
2. sujo é feito através de aprimoramento bytecode assim não há necessidade de ir para o armazenamento de dados para ver se um campo está sujo (e você pode ter controle sobre fechaduras quando você quer ir para o armazenamento de dados). Obviamente, isso dá vantagens significativas de desempenho ao longo implementações baseadas reflexão.
3. Não conheço nenhum "atualizações perdidas" possível; uso de bloqueio otimista ajuda.
4. Você pode obter atualizações implícitas devido a "relações gerenciados" (onde você tem uma relação bidirecional e só mudam de um lado, de modo DataNucleus atualiza o outro lado para ser consistente ... pelo flush ()). Você pode desativar "relações geridos" (até certo ponto). Você pode facilmente permitir versionamento de objetos e saber se um objeto é modificado ou não.

Razões para escolher DataNucleus são documentado aqui

HTH

- Andy DataNucleus

Answer 4

No que diz respeito ao Ebean ORM http://www.avaje.org e seu Armadilhas:

Remoting

Você pode usar o modo "vanilla" em uma consulta e, em seguida, Ebean voltará feijão simples e coleções. Isso só funciona quando você usa "proxies dinâmicos / subclasses dinâmicos", mas não se você usar Enhancement (como as classes de bean de entidade são, obviamente, reforçada).

verificação sujo é feito no banco de dados sem qualquer bloqueio .

Eu acredito que você quer dizer verificação de simultaneidade otimista? Se sim, então por definição, é feito sem um bloqueio DB explícito. Você precisa usar o bloqueio pessimista em vez se você quiser / precisar um bloqueio DB (selecione para atualização etc.) - então eu não seguir o seu ponto de lá

Atraso SQL

Ebean não tem sessões e por isso não tem nivelado sessão (). O SQL ainda pode ser adiada com Ebean quando você usa lotes JDBC, mas não é o mesmo atraso que você começa com rubor sessão ().

Atualizações implícitas

Uma queixa comum que ouvimos de pessoas ex-JPA ex-Hibernate e. Ebean é arquitetado sem uma sessão / entityManager. Em vez disso você precisa explicitamente save () um feijão ou ter que cascata de feijão relacionados. Então, sim, há atualizações implícitas com Ebean.