"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. 
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]

Responder a