Quais as vantagens de uso de DAO sobre CMP ?? 
Se usar DAO com Session Beans, perde a sincroniza��o automatica com o DB.
Se usar DAO com BMP, � mais uma camada, mais um instanciamento etc.
DAO/ BMP de um lado e CMP do outro, possivelmente perde portabilidade por 
motivo de uso de SQL nativo. Depurar SQL no BMP pelo menos � um saco. 
Perde tambem produtividade na implementa��o (CMP � muito mais facil).
O melhores motivos de uso de DAO em conjunto com EJB (Session ou Entity) 
s�o:
- O cliente j� tem uma camada de DAO
- Ser� criado uma aplica��o 'stand alone' fora da aplica��o WEB utilizando 
os DAO�s direto em vez da camada de EJB.
Eu realmente n�o vejo raz�o nenhuma aonde posso dezer que quando h� 
possibilidade de uso de CMP teria que optar por BMP ou DAO. O fato que o 
PetStore use(ava) BMP com DAO n�o quer dizer que isso � a melhor forma de 
implementar.

Robson Luis Ferreira <[EMAIL PROTECTED]> wrote on 29/10/2002 
11:17:18:

> 
>    Muito bem lembrado Julio, acredito que DAO � a
> melhor forma de se trabalhar com persist�ncia em BD. A
> thread ficou t�o focada entre BMP x CMP que esqueci-me
> desse detalhe, e confundi BMP e DAO.
> 
>    Grato
> 
> 
> 
>  --- Julio Cesar dos Santos Lins
> <[EMAIL PROTECTED]> escreveu: > 
> > Oi pessoal,
> > 
> > J� tenho uma boa experi�ncia com EJB e me convenci
> > de que n�o h� vantagem
> > alguma em utilizar BMP para persist�ncia -
> > considerando o cen�rio de
> > aplica��es realmente distribu�das.
> > 
> > A solu��o BMP com DAO s� traz desvantagens na minha
> > opini�o. Sou adepto de
> > duas alternativas: CMP ou DAO (sem entity beans
> > BMP). Sobre a solu��o BMP
> > com DAO, seguem alguns coment�rios:
> >    * Traz um overhead de distribui��o entre a camada
> > de neg�cio e a de
> > apresenta��o (EJB 1.1)
> >    * Tem um custo de manuten��o maior para fazer a
> > mesma coisa que um DAO
> > sozinho
> >    * Todo o controle de acesso concorrente feito pelo
> > container perde o
> > sentido quando temos mais de uma inst�ncia do
> > servidor.
> >    * Perde poss�veis otimiza��es de acesso a dados
> > feitas pelo container (ex:
> > Cache)
> > 
> > Vi que algumas mensagens levantavam BMP como uma
> > alternativa. Voc�s poderiam
> > levantar as poss�veis vantagens do BMP?
> > 
> > ps> Entity Beans realmente s�o desaconcelhados para
> > consultas do tipo
> > relat�rio (alguns campos de v�rias tabelas).
> > 
> > Um abra�o,
> > J�lio
> > 
> > 
> > > -----Mensagem original-----
> > > De: [EMAIL PROTECTED] [mailto:sven@;cilix.com.br]
> > > Enviada em: ter�a-feira, 1 de outubro de 2002
> > 10:49
> > > Para: [EMAIL PROTECTED]
> > > Assunto: Re: RES: [enterprise-list] CMP ou BMP
> > >
> > >
> > > Nem CMP nem BMP � bom para select de muitos
> > objetos uma vez que
> > > -possivelmente- o container instancia os 1000
> > registros como
> > > objeto. Neste
> > > caso sempre ser� muito mais aconselhavel usar o
> > value list handler
> > > pattern.
> > > Uso de entity beans � importante em sistemas
> > altamente transacionais e
> > > componentizados. CMP � o mais aconselhavel se os
> > entities mapeam
> > > diretamente para uma tabela e se na maioria dos
> > casos vc somente trabalha
> > > com poucos instancias de cada vez. Uma livraria
> > (parte de vendas) n�o
> > > deveria usar Entity Beans na parte de catalogo (o
> > cara pode achar 10000
> > > livros numa busca) mas sim para captar a venda (1
> > BookEJB, 1 VendaEJB e 1
> > > ClienteEJB).
> > > Na CETIP vc nao use EJB para busca de todas as
> > contas com > 1R$ de saldo
> > > ;-) ou faz ? Agora para frazer uma transferencia
> > vc deveria usar entities.
> > > Na maioria das vezes meus entities tem somente uns
> > 3 ou 4 finders (EX
> > > Cliente)
> > > - pk
> > > - CPF
> > > - id
> > > - telefone
> > > Pois s�o finders que retornam 1 ou poucos (mesmo
> > telefone pode existir em
> > > v�rias DDD).
> > > pesquisas em nomes parcias eu uso Value List
> > Handlers.
> > >
> > > Sven
> > >
> > > [EMAIL PROTECTED] wrote on 29/10/2002 09:33:56:
> > >
> > > > Swen,
> > > >
> > > > O CMP se comporta bem para select de muitos
> > objetos ?? Aquele problema
> > > das
> > > > 1001 'queries' para recuperar 1000 Objetos foi
> > corrigido na nova
> > > > especifica��o ??
> > > >
> > > > Olivier
> > > > JConcept/Cetip.
> > > >
> > > >
> > > > -----Mensagem original-----
> > > > De: [EMAIL PROTECTED] [mailto:sven@;cilix.com.br]
> > > > Enviada em: ter�a-feira, 29 de outubro de 2002
> > 08:23
> > > > Para: [EMAIL PROTECTED]
> > > > Assunto: Re: [enterprise-list] CMP ou BMP
> > > >
> > > >
> > > > > temos que ser profissionais. Lembre-se que a
> > penetra��o do
> > > JBOSS nelas
> > >
> > > > ainda
> > > > > � bastante restrita, que preferem Borland BES,
> > WebLogic, e o
> > > WebSphere
> > >
> > > > que
> > > > > por incr�vel que pare�a ainda est� na
> > especifica��o EJB 1.1 (a 2.0
> > > saiu
> > > > a
> > > > > pouco tempo).
> > > >
> > > > Daonde tirou isso ??? Weblogic foi o primeiro
> > app server a ser
> > > certificado
> > > > J2EE 1.3 (apos a paramati) !! BES � certificada
> > h� muito tempo tamb�m..
> > > J�
> > > > estou trabalhando com EJB 2.0 desde a vers�o 6.0
> > do WLS quando saiu o
> > > > upgrade de EJB 2.0 que foi em abril 2001 eu
> > acho.
> > > >
> > > > Quem � atrasado � IBM. Est� chegando EJB 2.1 e
> > eles est�o quase pronto
> > > com
> > > > EJB 2.0
> > > >
> > > > A regra que criei aqui na empresa sobre Entity
> > Beans � :
> > > > When designing entity beans a choice must be
> > made between Container
> > > > Managed Persistence and Bean Managed
> > Persistence. As a rule of thumb,
> > > the
> > > > Cilix Unified Process always uses Container
> > Managed Persistence, unless:
> > > > -       The specification requires Bean Managed
> > Persistence.
> > > > -       The Data-Store is NOT an RDBMS.
> > > > -       The Entity Bean does not map directly to
> > one table in the
> > > > database.
> > > > -       The client already has a DAO or JDO
> > persistence mechanism.
> > > > Unless specified as a prerequisite, the EJB
> > Specification to be used is
> > > > EJB 2.0.
> > > >
> > > >
> > > >
> > > >
> >
> ---------------------------------------------------------------------
> > > > 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]
> > >
> > >
> > 
> > 
> >
> ---------------------------------------------------------------------
> > Para cancelar a subscri��o, envie mensagem para:
> > [EMAIL PROTECTED]
> > Para comandos adicionais, envie mensagem para:
> > [EMAIL PROTECTED]
> > 
> 
> _______________________________________________________________________
> Yahoo! GeoCities
> Tudo para criar o seu site: ferramentas f�ceis de usar, espa�o de 
> sobra e acess�rios.
> http://br.geocities.yahoo.com/
> 
> ---------------------------------------------------------------------
> 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