aham! Sven, agora a fonte ficou beleza :)

------
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 grande 
    
de
  
objetos para o cliente. e como você disse EJB são transacionais, em cada 
    
get
  
que 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 necessariamente 
    
que
  
esses Entitys iriam para o cliente. é claro que eu utilizaria um método 
    
de
  
conversã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 que 
    
pra
  
cada relacionamento ele iria fazer uma nova pesquisa no banco. Ex. pego 
    
n
  
pessoas, pra cada linha desse retorno ele teria que pesquisar na tabela 
    
de
  
cidades. 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ê quis 
    
dizer
  
acessar 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. 
    
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]


  

Responder a