O problema est� mais em como usar do que em usar ou n�o. Primeiro V. precisa de boas ferramentas de desenvolvimento (Rose, WSAD, etc.), que fa�am todo o trabalho burocr�tico para V. Se n�o � melhor nem come�ar. O Java n�o foi feito para quem s� tem um editor de texto.
Com as ferramentas de desenvolvimento V. poder� criar os entity beans a partir de um banco de dados existente ou criar os beans e as tabelas a partir da modelagem. A partir dos entity beans crie data access beans para poder us�-los mais confortavelmente. Depois crie session beans com os m�todos de neg�cio e fa�a a ferramenta gerar os access beans correspondentes. O resultado fica mais ou menos assim: Servlet -> sessionAccBin.lista() -> sessionBean.lista() -> entityAccBean.findAll() -> entityBean.findAll() Isso funciona muito bem para transa��es simples de manuten��o, as tradicionais LISUD (list, insert, select, update & delete). A partir das vari�veis criadas nas interfaces remotas dos entity beans podemos derivar (copiar/colar/editar) facilmente: Struts-dynaforms, Struts validator definitions e tags de apresenta��o. A movimenta��o forms x data objects deve ser feita atrav�s de classes utilit�rias como BeanUtils, que copiam propriedades de mesmo nome de um lado para outro. O fato de as tabelas serem grandes n�o deve afetar sua aplica��o desde que as queries e o BD estejam otimizados, com os �ndices de performance corretamente definidos. O que causa problemas de performane: recupera��o e armazenamento em sess�o de listas muito grandes , listas com objetos complexos e transa��es complexas com muitos diferentes acessos ao BD. Os acessos complexos (joins de v�rias tabelas, loops em result sets elaborados para calcular alguna coisa) devem estar em session beans e ser cuidadosamente elaborados. Portanto, a grande vantagem inicial � minimizar custos de desenvolvimento e manuten��o, mas isso s� vai acontecer se todo o desenvolvimento estiver padronizado de acordo com as melhores pr�ticas e ferramentas dispon�veis (Rose, WSAD, Struts, etc.). V. pode esperar, para um ambiente de 1 �nico servidor como o descrito, tempos de resposta entre 2 a 5 '' por transa��o (mais que isso tem algo errado). Estes tempos poder�o ser melhorados futuramente distribuindo-se os componentes da aplica��o e a pr�pria aplica��o em mais de uma m�quina. Espero ter ajudado, Abs, ================================== Jos� Tito do Canto Paiva Self Inform�tica s/c Ltda. http://pws.prserv.net/selfinf Fax-Fone: 55 21 22214972 ================================== ----- Original Message ----- From: "linux" <[EMAIL PROTECTED]> To: "enterprise-list" <[EMAIL PROTECTED]> Sent: Wednesday, June 18, 2003 7:42 AM Subject: [enterprise-list] to be EJB or not to be > Caros Amigos, > > Em um projeto que estou envolvido estamos em um ponto de decisao sobre > adotar ou nao EJBs. > > Como nosso projeto tem um publico pequeno menos de 100 pessoas, visa > performance, utilizacao otimizada dos recuros de hardware (que sao > poucos) devo apontar as vantagens e desvantagens de se utilizar EJBs. > > Entao gostaria de fazer uma pergunta, levando-se em conta que: > > 1) A performance eh fundamental, pois a massa de dados manipulada eh > imensa. > 2) Nao havera processamento distribuido pois temos apenas > uma maquina HP-UX 32 proc. > 3) O tempo de desenvolvimento do projeto eh muito curto. > 4) O numero de usuarios eh bem pequeno. > > Quais vantagens e desvantagens voces vem em se utilizar EJBs? > > Gostaria imensamente de saber as opinioes e experiencias de voces. > > Muito obrigado > > Joao Pedro > > > --------------------------------------------------------------------- > Para cancelar a subscri��o, envie mensagem para: [EMAIL PROTECTED] > Para comandos adicionais, envie mensagem para: [EMAIL PROTECTED] > --------------------------------------------------------------------- Para cancelar a subscri��o, envie mensagem para: [EMAIL PROTECTED] Para comandos adicionais, envie mensagem para: [EMAIL PROTECTED]
