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

22

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.

Jazzepi
fonte
Você faz teste de unidade? Mudar as implementações não significa necessariamente produto acabado.
MrDosu 23/10

Respostas:

26

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.

codenheim
fonte
3
Concordo totalmente, essa também é a base da maioria dos problemas que tenho com o Hibernate em geral - compromete o SQL gerado para facilitar a troca do banco de dados. Ele também "faz um acesso" assumindo que é o melhor local para armazenar um cache de tabela, o que raramente é o caso da IMO. Há um caso de o Hibernate ter queda nos módulos de ajuste de SQL que transformam o HQL em Oracle, MySQL, SQL Server etc. SQL otimizado e param de fazer coisas estúpidas que o RDBMS faz melhor.
Mcottle
5

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.

jwenting
fonte
+1 para mencionar aplicativos em que o suporte a vários DBMS é um recurso. Se você oferece seu aplicativo para "auto-hospedagem" (algo que muitos clientes corporativos acham desejável), pode ser necessário. No entanto, você provavelmente ainda pode manter um ORM.
sleske
4

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.

scriptin
fonte
3

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.

Roland Tepp
fonte
1

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.

Jon Story
fonte