------ Diogo C. Catossi Infra-Estrutura de Sistemas Medisoft Ltda. Curitiba - PR - Brasil (41) 229-4247
[EMAIL PROTECTED] wrote:
"Maykel Tres" <[EMAIL PROTECTED]> wrote on 04/10/2002 11:07:35:Ficaram impraticáveis porque eu tinha que retornar uma quantidade grandedeobjetos para o cliente. e como você disse EJB são transacionais, em cadagetque eu executava ele abria uma transação até que o famoso OutOfMemory ocorreu. A minha dúvida seria em utilizar EJB para pesquisa. Não necessariamentequeesses Entitys iriam para o cliente. é claro que eu utilizaria um métododeconversão de Entity para Data Object.Claro, mas a quantidade de entities já quase garante impacto de performance. Uma instancia para cada registro. Dé uma olhada no pattern Value List Handler.Minhas pesquisas mais grandes já são implementadas em DAO. Até porque em alguns casos eu utilizo dados de várias tabelas pra montar uma linha de pesquisa. Isso em EJB é praticamente inaceitável devido o fato de quepracada relacionamento ele iria fazer uma nova pesquisa no banco. Ex. pegonpessoas, pra cada linha desse retorno ele teria que pesquisar na tabeladecidades. então ele executaria n pesquisas na tabela de cidades. certo?Não, joins são perfeitamente possivel, a mesma coisa que fará com DAO pode ser implementada com BMP.eu pretendo manter os EJB para persistencia, claro. Minha dúvida é nas pesquisas.Utiliza uma SessionFacade e o Value List Handler para pesquisas, EntityBeans para persistencia.mais uma coisa, você falou em utilizar Servlet/Jsp e DAO. Você quisdizeracessar o DAO diretamente pelo Servlet?Pode ser. Mas se vc realmente quer separar as camadas de apresentação de lógico de negocio, que aparentamente vc quer, Session Beans e Value List handler são a melhor opção.caso tenha escrito alguma bobagem por favor me corrijam. Maykel ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, October 04, 2002 10:42 AM Subject: Re: [enterprise-list] DAO x EJB Como assim ficou impraticavel?? Explica um pouco quais foram as problemas encontradas ?? Não se esqueça que um entity bean é um objeto persistente. Se vc tem queries que retornam grandes quantidades de registros, um bean deve ser instinciado para cada query. Um find no entity preferencialmente retorna um ou poucos registros. Se precisar usar uma lista para mostrar no lado cliente, há várias soluçoes de resolver isso numa maneira melhor. Deve lembrar também que um EJB é um objeto transacional. Se vc esta criando um sistema de Catálogo de produto por exemplo de qual o objetivoéde pesquisa, provavelmente é melhor utilizar somente Servlets/JSP e DAO. Se criar um sistema de negocios aonde a funcionalidade transacional é essential, a perda de performance de EJB em relação de DAO não necessariamente é impedimento de uso deles. Com EJB vc terá muito mais escalabilidade, segurança e estabilidade, transações distribuidos etc.Háaté servidores de aplicação com failover de transações. Integração com sistemas legados também será razão para uso de EJB. "Maykel Tres" <[EMAIL PROTECTED]> wrote on 04/10/2002 09:54:37:Ola pessoal, Já que está uma discussão de que se deve usar onde, eu peço outra ajuda dos senhores. Eu gostaria de saber, com a experiência de vocês, qual deveria ser a minha política de pesquisa. Eu deveria utilizar DAO(SQL) para pesquisas ou EJB(EJBQL)? Eu fiz alguns testes utilizando Entity no cliente e ficou impraticável, mudei para Data Objects e o desempenho melhorou muito utilizando DAO. Ainda não testei utilizando DO com EJB. O que vocês acham sobre o assunto? desde já agradeço pelas colaborações, Maykel Tres--------------------------------------------------------------------- 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: enterprise-list- [EMAIL PROTECTED] Para comandos adicionais, envie mensagem para: enterprise-list- [EMAIL PROTECTED]--------------------------------------------------------------------- Para cancelar a subscrição, envie mensagem para: [EMAIL PROTECTED] Para comandos adicionais, envie mensagem para: [EMAIL PROTECTED]
