JPA em projetos de Fabrica de Software pro Governo

Assuntos Gerais
#1

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?

#2

[quote=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?
[/quote]
Qual tipo de modelagem define que num relacionamento 1:1 a PK da tabela A seja a PK da tabela B? As que eu conheço, a PK da tabela A, no máximo, é uma FK da tabela B com um references para a PK de A. Enfim…
Não existe bala de prata, camarada.
Mesmo com JDBC e DAO e o que mais você imaginar, sempre existirá algum impedimento que torne o processo mais lento.
Além do mais, com JPA você consegue fazer tudo, pois existem as maravilhosas nativeQueries da vida.

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.

#3

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.
#4

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.

#5

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

#6

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.

#7

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 :slight_smile:

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

#8

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.

#9

[quote=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.[/quote]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. [=

#10

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

#11

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

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

#12

[quote=Hebert Coelho][quote=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.[/quote]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. [=[/quote]

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.

#13

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

Nesse projeto em específico, não. Mas em outros sim.[/quote]

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.

#14

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

#15

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

#16

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

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

#17

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.

#18

  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

#19

[quote=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.[/quote]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.

#20

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.