Quando você pode/deve ir até o fim com a abordagem ORM?

Question

Parece-me que a introdução de uma ferramenta ORM deve tornar sua arquitetura mais limpa, mas para maior eficiência, acabei ignorando-a e iterando um conjunto de resultados JDBC ocasionalmente.Isso leva a um emaranhado descoordenado de artefatos em vez de uma arquitetura mais limpa.

É porque estou aplicando a ferramenta em um contexto inválido ou é mais profundo do que isso?

Quando você pode/deve ir até o fim com a abordagem ORM?

Qualquer visão seria muito apreciada.

---

Um pouco de contexto:

No meu ambiente, tenho cerca de 50 computadores clientes e 1 SQL Server razoavelmente poderoso.

Eu tenho um aplicativo de desktop no qual todos os 50 clientes acessam os dados o tempo todo.

O Modelo de Dados do projeto passou por uma série de reorganizações por vários motivos, incluindo clareza, eficiência, etc.

História do meu modelo de dados

1. Chamadas JDBC diretamente
2. DAO + POJO sem relações entre Pojos (basicamente envolvendo o JDBC).
3. Adicionadas relações entre POJOs implementando Lazy Load, mas apenas ocultando as chamadas inter-DAO
4. Entrei no movimento do Hibernate depois de ver como ele tornava o acesso aos dados "simples" (tornava triviais as relações entre POJO) e porque poderia diminuir o número de viagens de ida e volta ao banco de dados ao trabalhar com muitas entidades relacionadas.
5. Como era um aplicativo de desktop, manter as sessões abertas por um longo prazo era um pesadelo, então acabou causando muitos problemas
6. Voltei para uma abordagem DAO/Hibernate parcial que me permite fazer chamadas JDBC diretas atrás da cortina DAO e ao mesmo tempo usar o Hibernate.

Answer 1

Hibernate faz mais sentido quando seu aplicativo funciona gráficos de objetos, que são persistidos no RDBMS.Em vez disso, se a lógica do seu aplicativo funcionar em uma matriz de dados 2D, buscá-los via JDBC direto funcionará melhor.Embora o Hibernate seja escrito sobre JDBC, ele possui recursos que podem não ser triviais de implementar em JDBC.Por exemplo:

1. Digamos que o usuário visualize uma linha na IU e altere alguns dos valores e você queira disparar uma consulta de atualização apenas para as colunas que realmente foram alteradas.
2. Para evitar impasses, você precisa manter uma ordem global para SQLs em uma transação.Fazer isso direito, JDBC pode não ser fácil
3. Configurando facilmente o bloqueio otimista.Ao usar JDBC, você precisa se lembrar de ter isso em todas as consultas de atualização.
4. Atualizações em lote, materialização preguiçosa de coleções, etc. também podem não ser triviais de implementar em JDBC.

(Eu digo "poder não seja trivial", porque é claro que isso pode ser feito - e você pode ser um super hacker :)

O Hibernate também permite que você dispare suas próprias consultas SQL, caso seja necessário.

Espero que isso ajude você a decidir.

PS:Manter a sessão aberta em um cliente de desktop remoto e ter problemas não é problema do Hibernate - você enfrentaria o mesmo problema se mantivesse a conexão com o banco de dados aberta por muito tempo.