Entity Beans não foram concebidos para implementar cada tabela do seu banco. A idéia é que se gere um modelo de pouca granularidade. Fazendo as coisas um pouco mais "grossas" traz vários benefícios dentre eles a redução do relacionamento entre entities. Procure pelo pattern Composite Entity.
By Alê! -----Original Message----- From: Leandro Bitencourt [mailto:[EMAIL PROTECTED]] Sent: quarta-feira, 17 de outubro de 2001 15:30 To: [EMAIL PROTECTED]; Felipe F. Palma Dias Subject: RE: [java-list] Re:RES: [java-list] Dúvida sobre EJBs - Uma consideração Importance: High Felipe, Nao sei onde vai rodar sua aplicacao, mas hoje em dia com a maioria das solucoes tentendo para a distribuicao de componentes e centralizacao de informacao, dificilmente vc terá um resultset com mais de 10 linhas... Agora, qto mais vc distribui e mais camadas vc cria, mais lento fica, nem tenha duvida disto. Abraços, Leandro Bitencourt [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> ICQ: 69948464 -----Original Message----- From: Felipe F. Palma Dias [mailto:[EMAIL PROTECTED]] Sent: quarta-feira, 17 de outubro de 2001 10:26 To: [EMAIL PROTECTED] Subject: Re: [java-list] Re:RES: [java-list] Dúvida sobre EJBs - Uma consideração Tb já me fiz esse questinamento, com fica o desempenho de uma aplicação EJB que usa Entity criando um objeto para cada registro de meu banco? -------------------------------------------------------------------------- Felipe F. Palma Dias - [EMAIL PROTECTED] http://www.palmadias.hpg.com.br ICQ: 133921121 ----- Original Message ----- From: "Giovani Salvador" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, October 17, 2001 7:53 AM Subject: [java-list] Re:RES: [java-list] Dúvida sobre EJBs - Uma consideração Só tem uma coisa a ser considerada no uso de entity´s para as tabelas. Como um entity cria uma instância para cada tupla recuperada, imagine um select que traga 5000 registros? -------- Mensagem Original ------------------- Data : Ter 16/10/2001 19:37 De : Eduardo Fabricio Elias <[EMAIL PROTECTED]> Para : '[EMAIL PROTECTED]' <[EMAIL PROTECTED]> Assunto: RES: [java-list] Dúvida sobre EJBs Luiz, Realmente, parece-me que o ideal é utilizar 1 entity para cada tabela, dividindo assim a camada de persistência da camada de regra de negócio, que ficaria a cargo dos session bean... Coisa de loco... Assim teria bem definido a interligação entre o mundo relacional e objeto. Eduardo Fabricio Elias Analista de Sistemas - Divisão de Informática Centro de Integração Empresa Escola - CIEE-RS Fone: 51 32847029 http://www.ciee-rs.org.br -----Mensagem original----- De: Elcio [mailto:[EMAIL PROTECTED]] Enviada em: sábado, 13 de outubro de 2001 20:20 Para: [EMAIL PROTECTED] Assunto: Re: [java-list] Dúvida sobre EJBs Olá novamente Luiz, Os EJBs são um campo novo para mim também. Embora não tenha, efetivamente, nenhum projeto na área, estou fazendo uma bateria de testes utilizando o JBOSS como conteiner, em uma plataforma totalmente open source. Meu interesse e testar os EJBs com Load Balance, ou seja simulanda gramde carga de solicitações e fazendo a distribuição do processamento entre duas máquinas diferentes... É tudo muito facinante, mais confesso que não tenho tido tempo necessário para fazer tudo que tenho vontade. Agente se fala, t+ Elcio ----- Original Message ----- From: "Luis Cabral" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, October 09, 2001 7:35 AM Subject: Re: [java-list] Dúvida sobre EJBs > Elcio > > Obrigado pela resposta tão detalhada. > Realmente há muitos conceitos novos, que até > consigo entender, mas o que me é difícil é vislumbrar > como uma aplicação real poderia ser estruturada > utilizando EJBs. Ainda há muito a estudar! > > Para o problema do pedido que citei, a opção > que devo usar é utilizando JSPs e servlets, sendo > que o processamento mais complexo (validações etc) > ficaria dentro do banco Oracle na forma de > Stored Procedures. Para mim, essa é a forma mais > fácil de implementar e com o melhor desempenho. > > Talvez EJBs não sejam a solução ideal para tudo? > > Se for possível, vc poderia citar em que tipo de projeto > vc utiliza EJBs, caso os use? > > Obrigado! > Luis Cabral > > ----- Original Message ----- > From: "Elcio Abrahão" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Sunday, October 07, 2001 8:50 PM > Subject: Re: [java-list] Dúvida sobre EJBs > > > > Caro Luiz, > > > > Enterprise Java Beans foram criados para facilitar a vida > > dos desenvolvedores de aplicações distribuidas. A idéia é que os > > EJBs sejam responsáveis pelo processamento da lógica de negôcios em > > seu sistema distribuidos. Os métodos dos EJBs são acessados através > > de Conteiners e os > > EJBs podem ser de três tipos: > > > > - Session Bens: podem conter métodos necessários a logica de sua aplicação > e > > podem ser divididos em beans que geram ou não variaveis de sessão. > > Os > beans > > que não geram variávies de sessão não persistem durante a sessão de > > um usuário, ja os que geram variáveis de sessão são persistentes > > durente toda > a > > sessão de um usuário. > > > > - Entity Beans: Você pode criar para cada tabela de seu Bco de dados > > um Entity Bean. Criar 25 Entity Bens pode ser a princípio assustador > > mais haverão algumas vantagens interessantes, pois o programador > > pode deixar > por > > conta do Conteiner do Bean a sincronização dos dados com o banco de dados. > > Esse processo é denominado Conteiner Managed Persistence (CMP). Utilizando > > este facilidade o programador não tem que mais se preocupar em > > redigir o código que faz a leitura, gravação de dados no Banco de > > Dados. Cada > momento > > em que há uma atualização no Bean esta atualização e sincronizada > > com o > Bco > > de Dados. Há ainda como continuar fazendo as gravações e leituras > > com > nosso > > código utilizando o Beam Managed Persistence, onde nós mesmo > > escrevemos os > > métodos para a sincronização do banco. A utilização de cada maneira > > é definida nos deployments descriptors de cada Bean. > > > > - Message Bens: Muito úteis quando desejamos enviar mensagens acincronas, > os > > seja não depende de resposta imediata, como as chamadas de método. > > > > Além do mencionado acima os EJBs fornecem as seguintes facilidades: > > > > - Pooling de Objetos: Vários Beans são colocadas em um pooling na memória, > a > > disposição dos usuários. Quando um bean é requisitado sua referência > > é passada ao usuário, o que aumenta a velocidade de processamento > > pois o > bean > > já está carregado, se todos os beans do pooling já foram utilizados > > e há mais uma requisição o Conteiner providência o carregamento de > > mais uma > cópia > > do Bean. Terminado o uso os beans voltam para o pooling. > > > > - Gerenciamento das Sessões dos Usuários: O Conteiner é responsável > > pelo gerenciamento das variáveis de seção de cada usuário. Assim se > > as sessões > > são compartilhadas por varios aplicativos em diverentes máquinas e locais > o > > Conteiner e responsável pela gravação dos variáveis de sessão e por > > seu posteiror reutilização. > > > > - Pooling de Connecções do Banco de Dados: O Conteiner também fica > > com a responsabilidade de fazer um pooling de connecções com o banco > > de dados. Aquilo que muitos de nos implementámos em nosso código, é > > feito automaticamente pelo Conteiner que mentem um certo número de > > conecçõs abertas e as distriui ou fecha conforme a necessidade da > > aplicação. > > > > - Gerenciamento de Transações: Olha só que interessante, agora você > > pode determinar que determinado método de um Bean é controlado por > > transação, > ou > > seja , quando o método é invocado é automaticamente inicializada um > > Transação, que pode ser Commitada no final, ou pode-se feito um roll-Back, > > veja bem um roll-back de um método !!! Isso tudo sem o programado escrever > 1 > > linha de código sequer.... > > > > - Gerenciamento de Segurança: EJB podem fazer o controle da > > segurança com > > mínima codificação por parte do programador, tanto autenticação de > usuários > > como checagem de nível de acesso. > > > > - Gerenciamento de Persistência: Como eu já descrevi no Item Entity Beans, > > basta declararmos no deployment descriptor quais as colunas de nosso banco > > SQL desejamos sincronizar que o Container cuida do resto. > > > > Enfim, os EJBs, são um pouco mais complexos que você deve ter > > imaginado, mais foram uma grande sacada do pessoal da SUN. > > > > Luiz, o que descrevi acima você poderá encontrar com mais detalhes > > no > livro: > > EJB Professional Ed 2001, da Wrox, são 1257 pags. > > > > Espero ter ajudado, provavelmente temos outros colegas que possam > contribuir > > mais com suas dúvidas, > > > > Abraço, > > > > Elcio A. > > > > > > ----- Original Message ----- > > From: Luis Cabral <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Sunday, October 07, 2001 9:44 AM > > Subject: [java-list] Dúvida sobre EJBs > > > > > > > Olá > > > > > > Tenho mais uma dúvida sobre EJBs. > > > (É que eu venho do ambiente cliente-servidor, > > > e tento entender o melhor uso de EJBs > > > comparando com aplicações "tradicionais"...) > > > > > > Imaginando um sistema cliente-servidor > > > tradicional, em que o usuário, por exemplo, > > > informa uma data, e o sistema traz todos os > > > pedidos daquela data. Aí o usuário pode > > > consultar e alterar o status de cada pedido. > > > E, por fim, ele clica algo e todas as alterações > > > são salvas. > > > > > > Se eu quiser desenvolver um sistema similar > > > utilizando EJBs (não importando qual seria o > > > front-end), como funcionaria? No momento > > > da consulta do usuário, seriam instanciados > > > "n" Entity Beans, que ficariam bloqueados até > > > o usuário confirmar as alterações? Ou a forma > > > correta seria inicialmente fazer apenas uma > > > consulta (como se fosse um relatório), e quando > > > o usuário confirmasse, aí sim seriam criados > > > Entity Beans para os registros modificados > > > para atualizar o banco? > > > > > > Em outras palavras, vejo que Entity Beans é > > > para manipular "linha a linha"... E quando o usuário quiser > > > alterar várias linhas ao mesmo tempo? > > > > > > Obrigado! > > > Luis Cabral > > > > > > > > > > > > > > > ------------------------------ LISTA > SOUJAVA ---------------------------- > > > http://www.soujava.org.br - Sociedade de Usuários Java da > > > Sucesu-SP dúvidas mais comuns: http://www.soujava.org.br/faq.htm > > > regras da lista: http://www.soujava.org.br/regras.htm > > > para sair da lista: envie email para > [EMAIL PROTECTED] > > > > ---------------------------------------------------------------------- > --- > > > > > > > > > > > > ------------------------------ LISTA SOUJAVA ---------------------------- > > http://www.soujava.org.br - Sociedade de Usuários Java da > > Sucesu-SP dúvidas mais comuns: http://www.soujava.org.br/faq.htm > > regras da lista: http://www.soujava.org.br/regras.htm > > para sair da lista: envie email para [EMAIL PROTECTED] > > ---------------------------------------------------------------------- > --- > > > > > > ------------------------------ LISTA SOUJAVA > ---------------------------- http://www.soujava.org.br - Sociedade > de Usuários Java da Sucesu-SP dúvidas mais comuns: > http://www.soujava.org.br/faq.htm regras da lista: > http://www.soujava.org.br/regras.htm > para sair da lista: envie email para [EMAIL PROTECTED] > ------------------------------------------------------------------------- > > ------------------------------ LISTA SOUJAVA ---------------------------- http://www.soujava.org.br - Sociedade de Usuários Java da Sucesu-SP dúvidas mais comuns: http://www.soujava.org.br/faq.htm regras da lista: http://www.soujava.org.br/regras.htm para sair da lista: envie email para [EMAIL PROTECTED] ------------------------------------------------------------------------- ------------------------------ LISTA SOUJAVA ---------------------------- http://www.soujava.org.br - Sociedade de Usuários Java da Sucesu-SP dúvidas mais comuns: http://www.soujava.org.br/faq.htm regras da lista: http://www.soujava.org.br/regras.htm para sair da lista: envie email para [EMAIL PROTECTED] ------------------------------------------------------------------------- ************************************************** Giovani Salvador http://pagina.de/siglas (Siglas de informática) PROCERGS - Cia. de Processamento de Dados do Estado do Rio Grande do Sul Setor TSI - Tecnologia para Sistemas de Informação ICQ #44904309 ************************************************** ---------------------------------------------------------------------------- ---- ------------------------------ LISTA SOUJAVA ---------------------------- http://www.soujava.org.br - Sociedade de Usuários Java da Sucesu-SP dúvidas mais comuns: http://www.soujava.org.br/faq.htm regras da lista: http://www.soujava.org.br/regras.htm para sair da lista: envie email para [EMAIL PROTECTED] ------------------------------------------------------------------------- ------------------------------ LISTA SOUJAVA ---------------------------- http://www.soujava.org.br - Sociedade de Usuários Java da Sucesu-SP dúvidas mais comuns: http://www.soujava.org.br/faq.htm regras da lista: http://www.soujava.org.br/regras.htm para sair da lista: envie email para [EMAIL PROTECTED] ------------------------------------------------------------------------- --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.286 / Virus Database: 152 - Release Date: 9/10/2001 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.286 / Virus Database: 152 - Release Date: 9/10/2001 ------------------------------ LISTA SOUJAVA ---------------------------- http://www.soujava.org.br - Sociedade de Usuários Java da Sucesu-SP dúvidas mais comuns: http://www.soujava.org.br/faq.htm regras da lista: http://www.soujava.org.br/regras.htm para sair da lista: envie email para [EMAIL PROTECTED] -------------------------------------------------------------------------
