[quote=chun]Entenda , seus argumentos não são validos… é chamar nego de burro dizer q um produto q custa 1 bilhao tem bug e nao eh corrigido… presta atencao… fica com o hibernate vai
[/quote]
Chun, obrigado por assumir que você não ter mais argumentos. Ou não tem idéia do que tá falando. E eu não falei de produto de 1 bilhão de dolares em lugar algum.
Todo software tem bugs. Ponto. Toda empresa só arruma os bugs que interessam a ela. Ponto. Se você não é capaz de compreender isso, vai ser incapaz de sobreviver nos negocios.
Você nunca deve ter participado de projetos sérios, você deve ser uma piada de um usuario do forum que quer tirar onda com os demais. Você é tão inverossimel nas suas afirmações que ou se trata de uma pessoa completamente alheia a realidade ou se trata de uma piada de mal gosto de alguem.
Guilherme, Entity Beans não devem ser usandos pela interface remota por que costumam possuir uma interface com granulosidade fina e isso é péssimo para objetos distribuidos. O ideal é usar Session Beans de fachada para eles.
Session Beans são ideiais para serem usados como objetos distribuidos já que deveriam possuir interfaces de granulosidade grossa.
Usar SLSB como fachadas pros EB é uma boa prática em j2ee.
Finalizando, chun, use BMP, eles permitem uma melhor flexibilidade no mapeamento entre os objetos e a base de dados.
(imaginem o Rafael com uma faca de cortar peixe na mao, arame-farpado na outra, um balde com alcool, sal, fogo e alguns outros apetrechos a mais a uma distancia de facil alcance. Entao imaginem agora ele aplicando isso tudo a certos “elementos”)
[quote=louds]Guilherme, Entity Beans não devem ser usandos pela interface remota por que costumam possuir uma interface com granulosidade fina e isso é péssimo para objetos distribuidos. O ideal é usar Session Beans de fachada para eles.
Session Beans são ideiais para serem usados como objetos distribuidos já que deveriam possuir interfaces de granulosidade grossa. [/quote]
eheheh essa eu aprendi esses dias … traduzindo pra conversa de gente normal (o que o louds não é ) isso significa que o EntityBean costuma ter as propriedades mapeadas pro infeliz do modelo entao tera chamadas como getName(), getMiddleName() e getFamilyName() e cada uma dessas geraria um punhado de trabalho de serializacao e outras coisitas na chamada remota …
enquanto isso no Session Bean vc simplesmente faz um getAllNamesAtOneTimeAndTogether() e pronto … :shock:
(soh pra constar pra quem usar a busca do forum)
Exatamente isso que o smota falou.
Um EntityBean alem dos getters, costuma ter operações simples.
E se você precisar chamar um monte delas para completar uma requisição vai ficar bem lento. Por isso usar um SessionBean como fachada, retornando VOs.
Pensa em uma pesquisa que precisa de acesso a 20 EB com 5 atributos cada, acessando eles remotamente, isso vai gerar umas 20x5=100 chamadas remotas, com um tempo de resposta de 10 ms por chamada vamos ter gasto somente com comunicação com a rede 1 segundo. Tempo demais dependendo do que estivermos fazendo.
Usando um SB como fachada vamos ter 1 chamada remota e 100 locais, assim poupando muito a rede de tráfego indesejado.
Tinha esquecido o detalhes do entity remoto como pessima ideia. valeu.
Entao se for usar o session distribuido (com qq patterns ‘escondendo’ isso), faz sentido deixa-los remotos, isso?
[quote]
Finalizando, chun, use BMP, eles permitem uma melhor flexibilidade no mapeamento entre os objetos e a base de dados.[/quote]
Analogamente, veja o processo de serializacao e a opcao de implementar seus proprios metodos de serializacao (MESMO QUE voce utilize serializable)… eh muito mais educado, performatico, produtivo e da mais liberdade implementar o seu proprio metodo
Sem contar as classicas restricoes da implementacao padrao
Desculpem-me mudar um pouco o contexto da conversa, mas pense no seguinte:
ejb é “potencialmente” melhor, mas não para a maioria dos casos dada a realidade da equipe, do prazo e do hardware envolvido.
O melhor dos objetos distribuídos é a distribuição do negócio(Session) pois distribuir os dados, isso o banco de dados já faz a muito tempo e bem.
E mais, não caiam na velha máxima de fazer do AS a melhor forma de acessar localmente uma aplicação distribuída.
) isso significa que o EntityBean costuma ter as propriedades mapeadas pro infeliz do modelo entao tera chamadas como getName(), getMiddleName() e getFamilyName() e cada uma dessas geraria um punhado de trabalho de serializacao e outras coisitas na chamada remota …