oooooo duvida cruel… CMP ou BMP ?
tenho um aplicativo que esta sendo contruido… client swing e j2ee no servidor… a pergunta eh…
devo persistir os dados do BD usando CMP ou BMP ?
quanto ao Hibernate , qual eh a vantagem REAL de usar ele… ?
pensando aqui estamos dentro da especificacao j2ee… sendo que hibernate nao eh da especificacao…
jah falow tudo
nem BMP nem CMP
use hibernate e seja feliz
:lol:
Opa… esse tipo de reposta nao dah neh ? vc agora jogou no lixo toda a funcao de um container ejb e diz que hibernate eh melhor…
quero saber o PORQUE … quero saber se ele h melhor em analise de casos medios… balanceamento de carga e distribuicao de operacoes… entity beans tira isso de letra… hibernate tem isso ? acho que vc nao me entendeu.
Hehhehehe
Bom eh o seguinte: vc tem q medir a complexidade que vc irá trazer com EJB’s … nao adianta vc pegar um container e colocar out-of-box e rezar pra dar certo, pq nao vai, vc vai ter q ter alguem especializado com isso… fora q seus desenvolvedores tem q realmente saber o q estao fazendo, prestar atenção na navegabilidade dos seus beans para evitar deadlocks na concorrencia dos dados, diminuir escopo transacional ao máximo, etc…
Bom em suma, existem frameworks bem mais leves que EJB q fazem a mesma coisa (dica: Spring + Hibernate)…
É tudo uma questão de pesar os prós e contras… mas por minha experiência com CMP , eu nao uso nunca mais (ou pelo menos ateh sair a 3.0 :-P)
Abraços
EXATAMENTE AE QUE EU QUERIA CHEGAR…
conta essa estoria ae sua com os CMP’s…
e o que vc espera tanto na versao 3.0…
Espero principalmente simplicidade de desenvolvimento, sem depender de otmizações obscuras do container para fazer funcionar…
Minha exp com CMP foi ruim, vários locks qando se colocava A, quando se colocava B a performance ia pro brejo… Muitas coisas…
Abraços
puxa , ae fica dificil , o que me tah parecendo eh falta de introsamento somente isso… de que adianta “simplicidade” se sua escalabilidade vai pro brejo ? da maneira simplista que vc esta me falando tah parecendo mais uma má implementacao do que realmente um problema do CMP , afinal , CMP eh usado em MUITOS lugares grandes… ex: Amazon.com faz mais de 1 milhão de transacoes por hora usando CMP e njao devem ter tuido esses locks…
well… estarei procurando ajuda de alguns professores de universidade… prq realmente se tem uma coisa que preso sao padroes… eles existem para que quando EU sair desta empresa ou quando outro entrar… nao tenha que ficar “imaginando” o que eu use… apenas pense… “usei especificacao j2ee”
Simplicidade nem sempre quer dizer producao… producao nao digo apenas no desenvolvimento inicial… e sim em TODO lifecycle do aplicativo…
Ok boa sorte…
Quando tiver sua própria experiência com CMP poste aqui pra sabermos o que aconteceu ok?
Abraços
Olha, EJB não é tão ruim assim.
Pelo menos minha experiência com BMP e CMP mostrou que os bichinhos funcionam. Mas o ponto principal da discussão é quando usar EJB’s.
O Eduardo disse uma grande verdade: Spring + Hibernate é uma das melhores combinações para demarcação de contexto transacional declarativo e utilização de Dependency Injection, o que diminui em muito o acoplamento de seus objetos, garantindo uma maior coesão do seu sistema.
EJB’s funcionam. Mas o ideal é conhecer muito bem seus life-cycles, entender como funciona a propagação de contexto de segurança, replicação de estado, etc para que possa utilizá-los em um contexto adequado.
Não use EJB’s por modismo cultural. Use quando é realmente necessário.
BMP são extremamente dificieis de serem usandos de forma escalavel, quase sempre se cai no problema do N+1.
CMP custa muito para se desenvolver e a performance não é lá das melhores. Apesar disso, existem containers muito escalaveis.
Outro fator importante é que EJB usado quando não existe uma demanda transacional forte não tem como dar conta do recado e você sempre tem que acabar usando um Fast Lane Reader.
Sem um expert no teu AS pra otimizar os deploy descriptors, a performance pode ser ate 10x pior.
Quanto a usar hibernate + spring, é uma solução muito mais produtiva e ambos produtos são de tão boa qualidade quanto os AS j2ee. Boa documentação e estabilidade de interfaces existem para ambos produtos.
Não vou comentar a questão da produtividade com EJB, que é muito inferior, mas sim da questão de escalibilidade.
O Hibernate tem suporte a caching em duas camadas, uma local a transação e outra global a aplicação, com possibilidade de ser clusterizado.
No final das contas, a única coisa que EJB te da a mais é um cache melhor de entidades, coisa que você teria que fazer um tunning mais manual com hibernate. Porêm para a boa escalabilidade de uma aplicação, essa não pode ser a única forma de caching a ser utilizada.
Se você tá realmente preocupado com estar 100% dentro dos padrões e 100% fora dos prasos. Use EJB.
Justamente , nao eh por modismo… e sim prq realmente estou vendo que EJB tem muitas vantegens e com ele consigo tratar clientes medios como clientes medios e clientes grandes como clientes grandes,…
atuamente minha aplicacao eh a mesma e tenho a mesma “seguranca” e “velocidade” nos dois casos… fora estar preso a linguagem SQL… mais uma coisa q me atraiu em EJB-QL…
detalhe… existe um “SERVIDOR HIBERNATE” ?
tirando os j2ee containers…
pelo jeito q vcs falam… com hibernate o cliente vira um .jar soh com tudo… regra de negocio + visual + banco
eh isso ?
ou estou errado ? e se estiver errado , me explique por favor como eh essa solucao hibernate…
EJB-QL foi uma das coisas q me fez odiar EJB´s… MUITO limitado, nada de order, nada de agrupamentos… Foi o q o Louds disse…
100% dentro dos padrões (putz tem cada uma dentrd desses padrões, uns may esquisitos na spec…) e 100% fora dos prazos…
Kra é muito fácil vc procurar relatos contra EJB´s na web… Olhe os fóruns pra vc ver o tanto de ´Problems with CMP´…
Bom é isso…
Abraços
PS: Hibernate é só o framework de persistência, nao ficaria sua aplicação toda no jar não, e se você souber fazer o negócio direitinho, dá pra abstrair a camada de persistência para seja mais suave a troca caso necessário…
[quote=duardor]EJB-QL foi uma das coisas q me fez odiar EJB´s… MUITO limitado, nada de order, nada de agrupamentos… Foi o q o Louds disse…
100% dentro dos padrões (putz tem cada uma dentrd desses padrões, uns may esquisitos na spec…) e 100% fora dos prazos…
Kra é muito fácil vc procurar relatos contra EJB´s na web… Olhe os fóruns pra vc ver o tanto de ´Problems with CMP´…
[/quote]
Bem , pelo que me pareceu… o EJB-QL nao tem como ideia principal “concorrer com o SQL” , e sim ser uma ferramenta… que vem evoluindo… e ORDER BY jah tem… na versao 2.1, e tem outra… pra q ORDER BY ? a Collections tem sort… onde posso usar N algoritimos para tal operacao… por enquanto o q tah parecendo eh que vc nao gosta da maneira de como funciona e nao que “nao funciona , nao eh produtivo”
Entao Hibernate apenas abtraria minha persistencia… o resto da padrozinacao EJB continuaria existindo ? “session” “messages” ?
o hibernate nesse caso seria apenas um modulo … isso ?
Detalhe sobre o EJB-QL , na PIOR DAS PIORES hipoteses… poria usar JBOSS EJB-QL , que suporta quase tudo de uma linguagem SQL normal… eu estaria sacrificando a portabilidade… mas posso usar em uma ou duas querys… o problema seria ficar preso a um container soh…
Porem… eh uma saida… estaria com uma “semi especificacao” , jah que as Querys na linguagem JBOSS-EJB-QL ficao em um .xml separado…
[quote=chun][quote=duardor]EJB-QL foi uma das coisas q me fez odiar EJB´s… MUITO limitado, nada de order, nada de agrupamentos… Foi o q o Louds disse…
100% dentro dos padrões (putz tem cada uma dentrd desses padrões, uns may esquisitos na spec…) e 100% fora dos prazos…
Kra é muito fácil vc procurar relatos contra EJB´s na web… Olhe os fóruns pra vc ver o tanto de ´Problems with CMP´…
[/quote]
Bem , pelo que me pareceu… o EJB-QL nao tem como ideia principal “concorrer com o SQL” , e sim ser uma ferramenta… que vem evoluindo… e ORDER BY jah tem… na versao 2.1, e tem outra… pra q ORDER BY ? a Collections tem sort… onde posso usar N algoritimos para tal operacao… por enquanto o q tah parecendo eh que vc nao gosta da maneira de como funciona e nao que “nao funciona , nao eh produtivo”
Entao Hibernate apenas abtraria minha persistencia… o resto da padrozinacao EJB continuaria existindo ? “session” “messages” ?
o hibernate nesse caso seria apenas um modulo … isso ?
[/quote]
Hehehe
Na prática a teoria é diferente…
Bom é o seguinte, vc poderia utilizar session, messages etc com Hibernate tb…
Já que você pode trazer os dados ordenados, pra que perder tempo (processamento, tempo de desenvolvimento, etc) fazendo isso fora do BD?
O que estou argumentando é que o Hibernate pode fazer quase tudo que os containers EJB´s fazem para PERSITÊNCIA… e é N vezes mais fácil de desenvolver utilizando Hibernate… mas se vc se sente confortável com EJB, go ahead… Só não diga que não foi avisado!
Abraços
O google pode ajudar a te convencer
Na verdade ninguem precisa te convencer, o que o duardor e louds estao tentando dizer é que existe vida fora EJB, e é uma vida mais feliz e produtiva :?
sim, o hibernate é só a persistencia … use o Spring pra outras funcoes (seguranca, transação, etc.) e algum framework para distribuicao em cluster de seus componentes (me ocorre o Coherence da Tangosol) …
Nao estar seguindo um padrao da sun nao quer dizer que nao existe um padrao, crie o seu se quiser.
Poderia ? vc fala como se o hibernate fisesse o mesmo papel… nao to entendo qual a solucao de aplicacao distribuida que vc propoem… eh HIBERNATE+O QUE ? prq persistencia nao eh a unica coisa que importa…
Essa desculpa que do “EJB-QL NAO TEM ORDER BY” nao tem como vc usar… EJB-QL 2.1 suporta order by… e como disse no maximo teria que extender em algumas querys usando JBOSS-EJB-QL , continuo vendo “que vc nao gosta da forma que eh feito” e nao que “nao faz” ou “eh ruim” , o conceito de ruim eh muito abstrato… “ruim” pra mim eh fazer um aplicativo em 1/10 do tempo que levaria pra fazer usando os padroes J2EE e ficar 10*10 do tempo pra fazer um alteracao ou para escalonar meu software…
Verdade, existe vida fora do EJB , essa nao eh a questao. EJB eh um contexto muito amplo , o negocio pelo jeito eh “Existe vida sem Entity beans CMP” , prq tanto Hibernate quanto Spring usao enterpise java baens
estou errado ? ( lembre-se em um contexto distribuido )
Tangosol e Coherence nao rodao debaixo de um container EJB ? aonde estaria ganhando ?
Verdade… em partes eh verdade… mas pense comigo… na hora de contratar um profissional… o que eh mais produtivo … contratar alguem que vai sentar na frente e saber o que fazer afinal j2ee eh uma especificacao… ou alguem que vai ter que descobrir suas artimanhas e seguir em frente ?
Yep … vc está errado.
Para o hibernate vc usa POJOs mesmo e para o Spring vc usar definicoes declarativas que no geral sao em cima de POJOs mas as vezes uma ou outra interface é requerida.
Vc pode sim usar EJBs de dentro do seu sistema baseado em Spring mas veja como um cliente qualquer, nenhuma relacao direta.
Nops … assim como para desenha sua solucao com o Spring para usar o Coherence tb nao eh necessario um EJB container.
Hummm … depende.
Se o caboclo que vc contratou nao eh tapado E vc usou algum padrao real (ou seja, definido e seguido) ele aprende e no fim das contas depois do 1o projeto ele provavelmente vai estar produzindo mais do que com EJB.
Só pra esclarecer tb … o EJB 3 será baseado no modelo do hibernate e o hibernate será uma implementação do EJB 3 … entonces se quiser seguir o padrao EJB tudo bem, daqui um tempinho vai estar usando hibernate mesmo assim 