| Autor |
Mensagem |
|
|
smota wrote:
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.
Esse POJOs eh um container de objetos distribuidos ? eh o q ? o Spring roda debaixo do q ? ele vai na aplicacao ou tem um "servidor de aplicacao rodando pra ele" ?
smota wrote:
Vc pode sim usar EJBs de dentro do seu sistema baseado em Spring mas veja como um cliente qualquer, nenhuma relacao direta.
ae vc me confundiu... o Spring fornece um Servidor de Objetos distribuidos ? somente ele e mais ninguem ?
smota wrote:
chun wrote:Tangosol e Coherence nao rodao debaixo de um container EJB ? aonde estaria ganhando ?
Nops ... assim como para desenha sua solucao com o Spring para usar o Coherence tb nao eh necessario um EJB container.
E como ficaria a distribuicao dos objetos ? quem faria ? acessaria usando que protocolo ? RMI-IIOP ? CORBA ? como conversar com a aplicacao ?
smota wrote:
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.
descordo totalmente... pensando assim eu desenvolveria em clipper , afinal das contas "um dia o cara aprende e produz mais" , mas respeito sua opiniao.
smota wrote:
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 
Exato... mas quem seguiu as especificacoes... tanto faz... se tah usando hibernate ou "jozereite" , afinal... estou dentro de uma especificacao e ela eh respeitada entre as versoes de J2EE , quando vier o proximo container... como ele vai trabalhar nao eh meu problema... o que me importa eh que vou jogar minha aplicacao e ela vai rodar, como tenho feito com testes em varios containers desde Sun até oracle... estou fazendo dentro da especificacao... nao mudo uma virgula... o maximo que tenho q fazer eh estanciar os pools para os objetos CMP , mas isso eh facin facin 
|
 |
|
|
smota wrote:
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 
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 )
smota wrote:
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) ....
Tangosol e Coherence nao rodao debaixo de um container EJB ? aonde estaria ganhando ?
smota wrote:
Nao estar seguindo um padrao da sun nao quer dizer que nao existe um padrao, crie o seu se quiser.
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 ?
|
|
|
|
duardor wrote:
Hehehe
Na prática a teoria é diferente... 
Bom é o seguinte, vc poderia utilizar session, messages etc com Hibernate tb...
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....
duardor wrote:
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!
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...
|
|
|
|
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...
|
|
|
|
duardor wrote: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´...
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"
duardor wrote:
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...
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... 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...
|
|
|
|
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...
|
|
|
|
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...
|
|
|
|
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....
|
|
|
|
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.
|
|
|
|
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...
|
|
|
|
vixe... falou mas nao disse nada
eu tenho esse livro ae em portugues e a ideia que ele passa realmente eh MUITO superficial quando chega nessa parte de interface local/interface remota... eu entendi o caminho que cada uma delas percorre... a pergunta eh... entre dois Beans no container... o proprio container escolhe a interface local quando eu chamar um EntityBean ?
|
|
|
|
Bom dia rapaziada...
gostaria de saber :
1) Quais as principais diferencas entre interfaces locais e remotas em EJB ?
2) Se eu for usar entity beans CMP , qual devo usar  ?
3) Se eu usar interfaces locais eu nao perco a escalabilidade  ? Digo, nunca conseguirei ter um controle de carga em varios servidores realmente eficiente ?
4) Alguem conhece algum exemplo de entity beans CMP usando 1:n ? 
Fico muito grato pela atencao de todos... 
|
|
|
|
well... descobri como...
vc tem que serializar um array de bytes caso queira passar algo como um arquivo ou um objeto em forma de arquivo...
ae eh soh passar o byteValue de parametro para seu entity bean
|
|
|
|
Gostaria de saber como fazer para passar um BLOB ( um arquivo... ) via EntityBean...
saka meu codigo...
Soh tah dando dau de "NotSerializableException" , na hora de passar o fileInputStream..... ok... se ele nao pode ser passado ... o que eh que pode ? quero mandar essa imagem para meu entity bean mas tah dificil :/
|
|
|
|