JPA em projetos de Fabrica de Software pro Governo

fabim:

Fala pessoal, levantar um assunto com vcs…

O que vcs pensam a respeito de “wow, vamos usar JPA sempre pq a parada é boa” quando a modelagem nem sempre ajuda?

Porque digo isso… a experiencia que passei de uns anos pra cá me mostra que, a nao ser que vc possa modelar o banco do jeito “esperado” pela JPA, os probleminhas e dificuldades que vão sendo encontrados no processo acabam custando tempo e excedem a “economia” de tempo que teoricamente seria obtida com o uso da framework…

Exemplo: relacionamentos 1 pra 1. Ele espera que a PK da Entidade 1 seja a PK da Entidade 2, já que se trata de 1 pra 1. Mas nem sempre o banco está modelado assim.
É apenas um exemplo, mas quando a base é mal modelada vc gasta um tempo TERRIVEL fazendo os “ajustes” pra que se enquadre na modelagem.

O exemplo que mais presenciei foi em fabricas do GOVERNO onde analistas de negocio e de sistemas não tem tanto aquela SAGACIDADE do pessoal do privado.
Dai vc tem que engolir uma modelagem tosca simplesmente porque já ta assim e pronto.

Outro complicador: vivemos no mundo REAL, e nele as empresas sempre contratam monkeys e haja saco pra esperar eles dominarem JPA.

Nesses casos nao seria melhor o velho DAO com SQL escrito?
Até porque deixa bem pratico escrever MERGEs (no caso de Oracle) e coisas mais especificas do banco.

O que pensam a respeito disso?

Mas, a minha posição é radical, se um projeto vai ser bem complicado com JPA, use só hibernate. Se vai ficar complexo, use só JDBC.
Sem crise, sem neuras. É mais trabalhoso, mas o resultado final é mais adequado.

Eu penso que se não tem sênior de JPA no projeto, vai ter muita dificuldade sim.

Na minha empresa tem gente que saca pacas de JPA, qualquer dúvida é só levantar a cabeça e pergunta.

Honestamente o único motivo que vejo para SQL seriam 2:

1. Questão de perfomance - Ainda assim, colocaria apenas a parte crítica em JDBC e o resto deixaria com JPA
2. O sistema for composto inteiramente de chaves compostas complexas. O Sênior tem que ser bom mesmo ou então o projeto pode passar uns perrengues por causa disso.

Ah, aproveitando o que o Hebert colocou, temos que ver do outro lado. Banco de dados não é apenas um enfeite. É um sistema à parte, que, em empresas sérias, possui um (ou mais) DBA que deve zelar pela performance. Isso pode cercear a liberdade dos desenvolvedores em criar coisas no banco (entenda-se fazer merda).
Do ponto de vista do desenvolvedor, o banco de dados deve ser um recurso e, como tal, utilizado com parcimônia e conhecimento.

Exatamente, no ponto em questão o projeto que mais está dando trabalho é justamente do ponto 2) chaves compostas pra TODO lado, everywhere

Este é um caso em que eu simplesmente odeio trabalhar.
Para mim, chave composta só deve ser utilizado em último caso e quando não há opção (ou seja, quase nunca).
De qualquer forma, você precisa lembrar que JPA é uma visão da parte orientada a objetos sobre um esquema estruturado. Logo, pode haver rebarbas a serem tratadas antes do acabamento ser aplicado.
Como o Hebert disse, se não há alguém com sólidos conhecimentos, você terá muitos, mas muitos problemas.

Eu sei bem como é que é isso, cara.

Já vi projeto onde tudo era chave composta, até mesmo coisa desnecessária, onde eu amaria que existisse uma chave artificial como PK. E fazer o mapeamento de tudo isso com JPA é uma chateação absurda.

O lado bom é que aprendi a fazer mapeamentos de todos os tipos e sabores possíveis com JPA, e acabei encontrando até uns bugs

Mas realmente, não é uma situação pela qual eu iria querer passar de novo

Entao pessoal, legal as respostas, foi por isso que levantei essa bola: nesse tipo de projeto com chaves compostas (desnecessarias em sua quase totalidade) estou considerando abolir da arquitetura usar JPA.

fabim:

Entao pessoal, legal as respostas, foi por isso que levantei essa bola: nesse tipo de projeto com chaves compostas (desnecessarias em sua quase totalidade) estou considerando abolir da arquitetura usar JPA.

Mas é aquela velha história né, amigo. Você tem a autoridade pra isso na sua empresa?

Mas é aquela velha história né, amigo. Você tem a autoridade pra isso na sua empresa?

Nesse projeto em específico, não. Mas em outros sim.

Hebert Coelho:

fabim:

Entao pessoal, legal as respostas, foi por isso que levantei essa bola: nesse tipo de projeto com chaves compostas (desnecessarias em sua quase totalidade) estou considerando abolir da arquitetura usar JPA.

se tem a escolha de não utilizar JPA, pq não tem a escolha de alterar a estrutura das chaves?
Os dois vão demandar esforço. [=

Pelo fato deu poder implementar as funcionalidades novas que me foram solicitadas de uma maneira que FUNCIONE.
Modelagem nao posso alterar porque já existem trocentos sistemas usando.

Imagine um órgao federal com 10 empresas terceiras, todas elas acessando a mesma tabela.

Mas é aquela velha história né, amigo. Você tem a autoridade pra isso na sua empresa?

Nesse projeto em específico, não. Mas em outros sim.

Sendo assim eu concordo com o Hébert. Talvez seja melhor revisar a modelagem, pois ainda acho mais fácil os “monkeys” como você disse fazerem “coisas” como o drsmachado com SQL do que fazer com JPA.

Galera rever modelagem em sistema criticos acessados por N sistemas nem sempre é uma opção

Essa informação de que o sistema é crítico e acessado por N sistemas é nova pra gente

Mas é aquela velha história né, amigo. Você tem a autoridade pra isso na sua empresa?

Nesse projeto em específico, não. Mas em outros sim.Então é só começar a largar o dedo. [=

Eu particularmente acho muito complicado usar JPA quando se tem muitas tabelas, muitas consultas complexas, etc…
Além de que, em determinados casos, utilizar funções nativas do banco da uma diferença gritante de performance.
Eu particularmente não gosto de JPA nem de Hibernate, embora acho que para alguns casos seja uma boa saída, mas pelo fato de não gostar, não sou a melhor pessoa para opinar.

1. Eu também acredito que JPA não se encaixa em todos os casos.

2. Ser sênior não significa menos trabalho ou menos problemas…alguém tem que pagar o pato se for sênior TALVEZ sofra menos.

Já pensou em utilizar algo menos sofisticado que ofereça simplicidade? Algo como o Ebean: http://www.avaje.org/doc/ebean-userguide.pdf

flws

fantomas:

2) Ser sênior não significa menos trabalho ou menos problemas…alguém tem que pagar o pato se for sênior TALVEZ sofra menos.

Não sei como é onde você trabalha, mas por onde passei era o sênior que tinha sempre a resposta na ponta da lingua. E se ele não tivesse a resposta engatilhada ele sempre encaminhou para a solução.

Eu também já sofri um pouco com isto, utilizando Hibernate em bases legadas. No começo foi o caos, mas depois de ter feitos diversos relacionamentos, o padrão (de relacionamentos) passava a se repetir. Depois que se “pega a manha” não é tão complicado assim ao meu ver.

Eu acho que vale a pena dar uma investigada, fazer alguns relacionamentos e ver se a maneira de criar os relacionamentos não é semelhante.

Agora, se começar a complicar muito, nem perde tempo. Usa um jdbc/dao de uma vez.

Tem o MyBatis que o mapeamento é feito direto do SQL para o modelo via XML. [=

fabim:

Exemplo: relacionamentos 1 pra 1. Ele espera que a PK da Entidade 1 seja a PK da Entidade 2, já que se trata de 1 pra 1. Mas nem sempre o banco está modelado assim.
É apenas um exemplo, mas quando a base é mal modelada vc gasta um tempo TERRIVEL fazendo os “ajustes” pra que se enquadre na modelagem.

Nem todo lugar é assim, o certo é o time ou pelo menos o líder participar da seleção de quem vai entrar no projeto. Não é obrigatório a pessoa saber determinada tecnologia, mas o time saber que a pessoa tem a bagagem fundamental e é capaz e muito interessada em aprender a tecnologia X. E no decorrer da vida todos se nivelarem, um aprendendo com o outro, respeitando diferenças atuais.

Hebert Coelho:

Hein?!
Se o sênior não está servidor para fazer o projeto andar tem coisa errada aí.

Não sei como é onde você trabalha, mas por onde passei era o sênior que tinha sempre a resposta na ponta da lingua. E se ele não tivesse a resposta engatilhada ele sempre encaminhou para a solução.

Até concordo, porem existem estas questões a meu ver:

1. O sênior sabe na ponta da língua porque ralou pra caramba por conta de uma dificuldade encontrada em uma tecnologia ou pela situação corrente ou porque foi ele mesmo que construiu aquele contexto > pagou o pato.
2. Sênior quando pega um legado (as vezes construído por estagiários) rala o * na pedra pra dar conta do recado…pode até ralar menos, mas rala; sênior não faz milagres.
3. Tecnologia bacana / uma boa solução tem que ser simples, a ideia é que a solução não seja mais complexa que o problema.
   …
   Entendi que você não disse isto mas aqui vai: Eu diria que em um ambiente onde, com frequência, o “sênior” tem que jogar a boia indica que algo não anda bem.

flws