JSF + HIBERNATE + JPA/EJB essa é a melhor solução?

Pois bem, não se preocupem não vou falar mau, mas vou dizer que eu como véio que sou nem perco meu tempo em “CONFIAR” os meus sql´s a ele,
vou direto o NativeQuery e pronto, eu falo por mim tenho muito mais resultados dessa forma do que acreditar que o Hibernate vai fazer melhor.

nao entendi esse seu ponto…mesmo com hibernate vc vai ter que criar as queries do mesmo jeito…as “regras” de como a query deve ser desenvolvida será a mesma…

alguma fez o hibernate ja ferrou suas queries?

ja uso a pelo menos uns 3 anos e meio e nunca tive problemas…

Mas vamos lá, JSF se for a 2.0 tem potencial, em JSP basico consigo o mesmo com muito mais eficiencia e rapidez.

Ta duvidando? Faz um Hello World em JSP puro e o mesmo em JSF e me responda … qual pagina abre primeiro?

Concordo!! Abre + rápido!!! Só acho q HelloWorld não é uma boa comparação…

Além do mais é possível ter ambientes rápidos com uma boa configuração e conhecendo bem a tecnologia… JSF vc abre mão de desempenho sim… más com certeza tem 1000x mais produtividade… Ai vai de que sistema vc ta fazendo…

Pra esse caso aconselho a leitura de arquitetura de sistemas coorporativos, do Fowler… Acho que se ele te visse escrevendo isso ele teria um treco…hahahah… com todo respeito… hoje em dia é interessantíssimo vc ter um framework para persistência… Além de que a perda de desempenho pode ser compensada com uma arquitetura descente… Um bom controle de LazyLoad por exemplo… Eu pessoalmente não teria coragem de escrever meu programa pra um unico vendor…

Concordo que são casos e casos… más acho que seria raríssimo um caso onde não valeria a pena hoje… O Fowler, no seu livro, comenta muito que o custo de um software é com certeza muito maior que de um hardware… muitas vezes compensa perder um pouco em desempenho e comprar uma máquina mais parruda (Realmente… se fosse na sua juventude, talvez isso não se aplicaria… rs… com todo respeito… os tempos mudam…)

Acho que nossa área é isso mesmo… vc tem q lutar para não ser relusente ás novas tecnologias…

Claro que coloquei dessa forma para gerar polemica, logico que vou “CONFIAR” no hibernate para os meus sql basicos, mas existe situações especificas das nossas aplcações e cabe mais voce usar o nativequery e a partir dai voce meio que foge do conceito de não ficar preso ao Banco de Dados especifico.

Mas mais do que isso é explicar os porques pra Galera, falar simplesmente não adianta.

Exemplo:

Se tenho uma tabela filha endereco e uma pai bairro, basta criar o objeto endereco que tenho todos os campos da tabela pai bairro, ou seja voce só precisa se preocupar na quantidade de registros retornados, senão meu amigo … de repente nem executa, lembre… tudo que retornar do banco vai para a memoria dentro de uma List por exemplo.

Se falei algo errado por favor me corrija.

Mas e se eu simplesmente pego crio um resultset e coloco em um while, será que não tenho uma solução mais rapida???

Existe um assunto sobre isso na Java Magazine, só pra lembrar e até onde entendi do texto, de repente fica a questão será que vale a pena usar JPA???

Abraços

Jomello

Acho que aqui ja é perceptivel que existem casos e casos.

Eu mesmo trabalho com um tabela que por conter muitos registros, retiraram as chaves para que quando carregadas no banco, nao causem uma sobrecarga de informações excessivas. (muitos registro = + 5000000)
JPA/HIBERNATE, ja nao se aplicam nesse caso. Entao sou obrigado a montar minhas querys na mao. Em contra partida, temos uma aplicação web que usa e abusa do hibernate e jpa. A produção vai é muito mais rapida, e concordo com o que foi falado, com um controle bem trabalho nos carregamentos dos objetos ja da uma boa economia de memoria ai.
Sobre jsp e jsf, deixo a desejar um pouco na opiniao, mas acho que mesmo as duas tecnologias sendo muito boas, vejo de longe a quantidade de componentes disponiveis no jsf, que feliz ou infelizmente, deveriam ser criados no jsp como tags novas.
Ai vem aquela …ORAS,…VC SO IRIA CRIAR UMA VEZ…
mas …quem é que vai criar todos os componentes no jsp …se vc ja tem no jsf?
Isso sem considerar os direcionamentos de paginas que sao mais faceis de fazer no jsf do que no jsp.

Entao, pra nao fugir do tema, performance, minha opiniao é …hoje em dia, performance é estudada no desenho do projeto. Voce nao escolhe qual framework vai usar so pela performance, se voce nao sabe como vai ser seu projeto. Por que se escolher os frameworks sem saber o que vai fazer, voce nao esta escolhendo por performance, esta escolhendo por gosto. Cada caso é um caso, assim como dizer que orientação a objetos nao é a melhor solução hoje em dia ( :shock: ???). Se é assim, vamos voltar a fazer sistemas em c, ou assembly. :twisted:

Abraços

Bacana Vinicius sua resposta, que alias é o nome do meu filho

Mas vamos lá, estamos falando em termos de produtividade e efeciencia que é o que vale hoje em dia, claro que amei o JSF só não concordo com a demora dele só isso.

Se voce ler com atenção veja que falei do JSF 2.0 que é uma das preocupações deles proprios ok

Opaaa… muita calma nessa hora, no que tanje ao Hibernate, logico que os caras fazem um trabalho gigantesco para melhorar o Hibernate, mas nem adianta falar o contrario, existe situações impares no nosso dia a dia que somos obrigados a usar nativequery, parto desse principio, se preciso uma unica vez, por que então tenho que ficar preso?
Porque então não posso ir direto e procurar a melhor solução para os meus problemas?

E vamos concordar no conceito MVC, todo mundo joga fora o proprio Banco de Dados e eu como véio que sou sei que resolvo muito mais coisas com stores procedures do que ir atras de JPA e bla-bla-bla… sem querer ofender ninguem, claro com todo o respeito ok amigos.

Sem falar o basico né, tudo que rola direto no banco é bem mais rapido e seguro né

Concordo que são casos e casos.. más acho que seria raríssimo um caso onde não valeria a pena hoje... O Fowler, no seu livro, comenta muito que o custo de um software é com certeza muito maior que de um hardware... muitas vezes compensa perder um pouco em desempenho e comprar uma máquina mais parruda (Realmente.. se fosse na sua juventude, talvez isso não se aplicaria.. rs... com todo respeito.. os tempos mudam...)

Fala isso pro seu cliente, em que ele tem que pegar o seu servidor que atende hoje suas necessidades e tem que comprar um novo?

Calma o mundo roda de forma diferente, voce como profissional é que tem que encontrar a melhor solução para o seu cliente e NUNCA ele que tem que se adaptar as suas necessidades.

Claro que toda regra tem excessões, logico que vale a pena investir, mas ai entramos em um novo contexto

Abraços

Jomello

é…aqui eu concordo, depende muito da situação pra falar que ele tem que comprar outra maquina, diria mais, na maioria das vezes
nao da pra falar isso.
Trabalho em uma empresa de licitações, e falar pra uma prefeitura, que ela tem que comprar uma maquina nova, é pedir pra ser mandado embora…rsrs…entao…aqui realmente tenho que ceder pro resultset…rsrs :lol:

È isso ai Kaiser voce entendeu o espirito da coisa.

Mas te digo se quiser alta performance com JSP + AJAX

Tem uma galera boa nessa area:

DWR - Apesar de dar uns paus as vezes e parece que não esta sendo continuado, da para usar para recuperar quanitdades pequenas de dados na boa (10000) e/ou usar para mandar os dados dos formularios tambem rola na boa.

Quanto a Ajax, dhtmlx-componentes ou dojo

Em termos de Grid vale mais a pena o dhtmlxGrid do que o do Dojo ok

Mas em termos de qualidade nada se compara ao RichFaces, mas não chega perto em termos de performance do dhtmlxGrid por exemplo

Abraços

Jomello

Haaaa… faltou um trem …

Ja lancaram o DojoFaces, é hoje apenas um forma de usar o DOJO junto com JSF, mas vale a pena dar uma olhada ok.

Abraços

Jomello

jomello_br:

Claro que coloquei dessa forma para gerar polemica, logico que vou “CONFIAR” no hibernate para os meus sql basicos, mas existe situações especificas das nossas aplcações e cabe mais voce usar o nativequery e a partir dai voce meio que foge do conceito de não ficar preso ao Banco de Dados especifico.

Mas mais do que isso é explicar os porques pra Galera, falar simplesmente não adianta.

Exemplo:

Se tenho uma tabela filha endereco e uma pai bairro, basta criar o objeto endereco que tenho todos os campos da tabela pai bairro, ou seja voce só precisa se preocupar na quantidade de registros retornados, senão meu amigo … de repente nem executa, lembre… tudo que retornar do banco vai para a memoria dentro de uma List por exemplo.

Se falei algo errado por favor me corrija.

Mas e se eu simplesmente pego crio um resultset e coloco em um while, será que não tenho uma solução mais rapida???

Existe um assunto sobre isso na Java Magazine, só pra lembrar e até onde entendi do texto, de repente fica a questão será que vale a pena usar JPA???

Abraços

Jomello

Já me deparei com isso… Vc simplesmente resolve com um bom mapeamento de lazy-load e em alguns casos extremos retirando as chaves (eu não gosto dessa solução)

jomello_br:

Bacana Vinicius sua resposta, que alias é o nome do meu filho

Fala isso pro seu cliente, em que ele tem que pegar o seu servidor que atende hoje suas necessidades e tem que comprar um novo?

Calma o mundo roda de forma diferente, voce como profissional é que tem que encontrar a melhor solução para o seu cliente e NUNCA ele que tem que se adaptar as suas necessidades.

Claro que toda regra tem excessões, logico que vale a pena investir, mas ai entramos em um novo contexto

Abraços

Jomello

Tudo bem amigo? Vamos lá pra nossas criticas construtivas novamente…rs.

Nos projetos que trabalho, é comum aplicarmos métricas de software para esses casos… Quando precisamos iniciar um novo projeto, necessariamente temos que justificar os custos… E o que sempre vejo é a mesma coisa…

Por exemplo: Você acha que vale mais a pena parar uma equipe (ou uma parte dela) para desenvolver toda a camada de persisência de uma aplicação corporativa (grande porte) ou investir em hardaware? É uma conta simples… e que em 99% dos casos vai cair no mesmo paradigma: Hardware é muito mais barato hoje…

Más ai q vem o porém… Se vc não consegue comprovar que isso sai mais caro provavelmente é pq vc não tem aplicado métricas eficientes… Ou ainda… se for o caso… pq vc trabalha com empresas pequenas que fica muito complicado justificar qualquer coisa… seja ela custo com hardware ou desenvolvimento…

É claro também que se vc tem um software pequeno, não justifica perder desempenho com Hibernate se sua “camada de persistência” (que provavelmente não vai precisar de muita coisa… Vc não ve a possibilidade de migração de banco por exemplo…). Olha que eu usaria isso se realmente minha aplicação utilizasse muito recurso e que não valesse realmente a pena…

É o que eu digo… tem casos e casos…rs… Más até agora Hibernate resolveu o meu… O ganho em produtividade compensa o preço…

:shock:

jomello_br acho que vc não seja tão véio assim, aliás tenho a impressão que existem pessoas mais véia que vc neste forum.

Vamos aos pontos:

1. JPA / Hibernate e similares não tem como principal objetivo a velocidade, muito embora em alguns casos vc possa atingir maior performance em relação ao JDBC puro pelo fato deles utilizarem caches.

2. Os frameworks para páginas (view) (jsf,flex,zk e etc) TAMBEM não possuem como objetivo principal a velocidade, inclusive as equipes alertam sobre esta questão. Sem citar o fato da incompatibilidade com os navegadores.

3. Os frameworks visam padrão e produtividade e como bonus você poderá ter a chance de obter performance em alguns casos.

4. Não foram (os frameworks) feitos para todos os tipos de projetos.

5. JPA / Hibernate e similares NÃO são indicados para bases de dados legadas.

6. JPA / Hibernate passa a visão de ser algo simples de utilizar MAS NÃO É, requer muito estudo atenção e criatividade para tirar o melhor deles nas piores situações.

7. Se o software é de uso interno (construido para uso dentro da própria organização) em locais onde a aplicação utilizará apenas um banco de dados o uso do ORMs perde um dos seus principais valores, utilizar vários bancos com pouca ou nenhuma alteração.

8. Em empresas que vendem software os ORMs se encaixam muito bem, clientes variados bancos de dados variados.

9. Bom senso é uma coisa necessária, utilizar uma solução única para todos os problemas não é bem indicado.

10. Ganho de performance praticamente imperceptíveis são altamente questionados em relação a produtividade.

…

Resumindo…se vc consegue um projeto novo em folha onde pré-requisito a respeito do tempo de resposta é tranquilo e o tempo para desenvolver é curto; prá que sofrer? (considerando o bom domínio das opções tecnológicas).

Já desenvolvi software utilizando máquinas de 8 bits e me lembro bem da preocupação em relação ao uso da memória; ainda continuo com esta preocupação acho saldavel e força o desenvolvimento de códigos melhores porém como vc mesmo disse - muita calma nesta hora.

Se você pensar bem a fundo vc pode acabar concluindo que o banco de dados relacional também pode ser um impecílio. Antes o pessoal utilizava basic com arquivos e muitos não reclamavam. Hoje existem bancos OO com formas de registros e controles fisicos similares e muitos morre de medo de utilizar; dá uma olhada no que a equipe do PREVAYLER http://www.prevayler.org/ fala e vc vai me entender. Não estou dizendo que o PREVAYLER é bom http://pt.wikipedia.org/wiki/Prevayler, apenas existem paradigmas diferentes.

E por último, dá para melhorar a perfomance um pouquinho mais se desenvolver só com servlet, sem utilizar JSP. Você ganha aquele tempinho que o servidor leva para incluir a página no ciclo de vida que leva até chegar a um servlet propriamente dito; pergunto, vale a pena? Questão de proporção certo?

Tópico interessante, valeu.

flws

fantomas, um dos meus seriados favoritos

(fantomas… fantomas… me ajude… plim-plim ai aparecia aquele morceguinho )

E ai meus amigos, tudo bem com voces???

Bom o tempo passou esse véio cresceu e aprendeu…

Portanto, quero apenas colocar a minha humilde opinião:

Sim como disse ontem, JSF 2.0, realmente resolve quase todos nossos problemas em termos de view.

Sim o Hibernate é e acredito sempre será o melhor framework para persistencia de dados, claro que:

Se voce for usa-lo somente com um unico Banco de Dados, não exclua a possibilidade de usar as caracteristicas desse banco (afinal esse produtor faz um trabalaho bacana para te dar ferramentas boas para solucionar seus problemas ok).

Se voce for usa-lo mult-bancos, beleza, mas lembre que voce vai ter que programar um pouco mais para resolver problemas simples ok.

Mas se voce quiser alta-performance em termos de consulta ao Banco de Dados, ai meu amigo JDBC nele

Haaa… eu mesmo ja fiz uns testes parece doideira, mas em alguns casos extremos funciona Hibernate and JDBC, voce vai ter o mundo ideal

E finalmente…

Vamos dançar amigos… heeeeee Bom Carnaval a todos e fiquem com Deus

Abraços

Jomello

kkkkkkkk!

Valeu Jomello.

Aquele abraço.