Manter a implementação agnóstica realmente vale a pena?

Eu tenho um projeto no qual estou trabalhando atualmente usando Tomcat, Spring 4, Spring Security, MySQL e JPA com Hibernate.

Escolhi o JPA do ponto de vista de que é suposto tornar a troca da implementação subjacente dos fornecedores de ORM ininterrupta ou pelo menos menos dolorosa. Eu diria que isso é usar mentalmente a especificação sobre a implementação (JAX-RS) como ponto de vista padrão da comunidade de desenvolvimento Java.

Estou curioso para saber se essa é realmente uma tarefa que vale a pena realizar. Tenho certeza de que, se usasse o Hibernate diretamente, ganharia um pouco de energia, pois poderia usar recursos que não fazem parte da especificação principal do JPA.

Parte da minha preocupação vem da idéia de YAGNI. Estou essencialmente programando em um estilo e moda específicos (usando o JPA em vez do Hibernate) para que, em algum momento no futuro, eu possa trocar minha implementação do ORM. Duvido muito que isso aconteça ao longo da vida útil do produto, por isso estou me esforçando para algo que provavelmente nunca colherá os benefícios.

Quais são seus pensamentos? A "programação para a interface" vale a pena quando se trata de coisas como JPA? Você já trocou uma implementação inteira do ORM em um produto? Você já foi capaz de evitar completamente a abstração de algo como o JPA vazando? Pessoalmente, eu já tenho uma única chamada SQL nativa (para limpar as tabelas do banco de dados), e há algumas que eu gostaria de usar com as que estão incorporadas na especificação JPA (prefixos get / set para seus métodos e a diferença entre MEMBER OF / IN, que apenas me vinculando a uma implementação subjacente me dará alguma chance de evitar.

para que em algum momento no futuro eu possa trocar minha implementação do ORM. Duvido muito que isso aconteça ao longo da vida útil do produto, por isso estou essencialmente me esforçando para algo que provavelmente nunca vou colher os benefícios de

Na minha experiência, o projeto típico da empresa nunca muda:

1. Base de dados
2. ORM
3. Língua

Não sei os números, mas a porcentagem de aplicativos de duas camadas que vi implementar e depois alterar uma dessas coisas provavelmente seria menor que 10%. Se isso acontecer, é raro e geralmente ocorre nos primeiros 2-3 meses do projeto, quando as pessoas ainda estão no modo de descoberta. A maioria dos sistemas que conheço ainda está sendo executada em suas plataformas originais 8 a 10 anos depois.

Mais frequentemente do que trocar um ORM, você quer saber o que eu vi mais? Removendo o ORM completamente para cair no SQL devido a problemas de desempenho. Então, não importa o que, nesse caso, você reescreva as coisas.

Tanto quanto a implementação agnóstica, é um mito. Realmente equivale a emburrecer. Então, minha abordagem é abraçar a camada de dados. Faça dele uma parte de primeira classe do seu idioma e design. Isso cria projetos mais felizes e bem-sucedidos.

Vale a pena?
Isso dependeria inteiramente da aplicação.
Se você estiver escrevendo um aplicativo interno para uma única empresa, esqueça. Esse banco de dados sobreviverá ao aplicativo por anos, possivelmente décadas.
A menos, claro, que você tenha entendido desde o início que o banco de dados está planejado para ser substituído por outra coisa no futuro próximo.
Se você está escrevendo para venda a clientes, que podem ter diferentes mecanismos de banco de dados, E os requisitos são de tal forma que ele deve suportar vários mecanismos de banco de dados, ENTÃO faz sentido.

Para a maioria das pessoas que cria aplicativos Java, isso é irrelevante.

Da minha experiência: não, não vale a pena no caso do JPA / Hibernate.

A "programação para a interface" vale a pena quando se trata de coisas como JPA?

É, mas não tem nada a ver com JPA especificamente. Você pode "programar para as interfaces" do Hibernate. Não se trata de ocultar uma estrutura sob um padrão, é sobre o SOLID .

Você já trocou uma implementação inteira do ORM em um produto?

Sim e não. Um dos produtos da nossa empresa migrou parcialmente do Hibernate para o jOOQ (que não tem nada a ver com JPA). Não era exatamente um "projeto corporativo típico" que a @codenheim mencionou, portanto a troca foi possível.

Não vejo sentido em trocar o Hibernate por outro ORM compatível com JPA.

Você já foi capaz de evitar completamente a abstração de algo como o JPA vazando?

Não. É impossível porque o JPA e o Hibernate são muito complexos. E você precisa lidar com os problemas de desempenho do Hibernate e as falhas de design de qualquer maneira.

Correndo o risco de parecer contrário aqui, eu diria que sim, vale a pena. E não é.

O problema não é tanto mudar o ORM ou o provedor de banco de dados como tal. É mais uma questão de separação de preocupações e permanência ágil.

Depois de começar a confiar em alguns detalhes de implementação de uma biblioteca, você começa a criar emaranhados cada vez mais profundos de preocupações.

Se você sabe que sua implementação do ORM é Hibernate, esse conhecimento começa a escoar toda a arquitetura do seu aplicativo. E sempre que surge uma nova tecnologia que substitui o Hibernate ou o JPA tão completamente quanto o Hibernate fez com o que veio antes, você descobre que as dependências se tornaram muito mais profundas do que o esperado.

É muito melhor afastar toda a preocupação de manter seu modelo em algum lugar fora do caminho, onde todos os meandros de lidar com bancos de dados e transações e outros enfeites podem ser facilmente ignorados pelo restante do aplicativo. Nesse canto escuro remoto, você pode se amarrar nos detalhes específicos da implementação, se quiser - isso realmente não importa mais.

O problema com o agnosticismo de implementação é que, no seu tempo como desenvolvedor, você perderá tempo de qualquer maneira.

Escrevi vários projetos que desperdiçamos muito tempo escrevendo em uma interface, que nunca foram usados ​​de nenhuma maneira nova, nunca foram convertidos e usados ​​apenas "como estão" por anos

Também perdi muito tempo convertendo software que ninguém esperava que fosse convertido.

A única observação real que tenho que fazer é que a primeira é muito menos dolorosa.