Essa thread CMP x BMP est� ficando interessante. Eu vi que algum colega falou que os ger�nciadores de persist�ncia s�o feitos por pessoas que entendem e por isso s�o bons. Bom, o que eu vejo, � que o nosso colega realmente tem raz�o, as implementa��es s�o muito boas (ex JBossCMP). Mas o grande problema � que a especifica��o � uma droga. N�o � nem fraca... ou incompleta, � uma droga mesmo.
Por exemplo: a EJB-QL s� pode ter sido especificada por autistas que nunca escreveram um software cr�tico na vida. Como uma linguagem de pesquisas n�o tem LIKE parametriz�vel ? Quanto aos CMP 1.x s� pode ser piada aquilo. Eles n�o possuem os CMR, os atributos de liga��o. Isso implica em termos um modelo de componentes que mais se parecem com as tabelas do que com qualquer outra coisa. Isso � ridiculo, nenhum mecanismo de persist�ncia do passado era t�o ruim assim. Os CMP 2.x realmente s�o muito melhores. Eu at� gosto deles, s� sinto falta de algumas coisinhas... mas � uma op��o melhor que BMP, na minha opini�o. Eu digo isso por que se o ger�nciador de persist�ncia for bem feito (aten��o, s� se for bem feito) voc� escrever� CMPs com mais velocidade que BMP para que ambos possuam uma excelente qualidade. Os abstract setters & getters podem ajudar na otimiza��o criando para isso as vari�veis dirty da vida. Algo que eu nunca tive a oportunidade de ver em produ��o, mas que eu realmente gostaria muito de ver � Session Beans + JDO. Engra�ado isso, mas eu gosto muito mais de JDO do que de EntiyBean. Mais uma vez, opini�o pessoal. []'s ----- Original Message ----- From: "Julio Cesar dos Santos Lins" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, October 29, 2002 12:04 PM Subject: RES: RES: [enterprise-list] CMP ou BMP > > 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] > > --------------------------------------------------------------------- Para cancelar a subscri��o, envie mensagem para: [EMAIL PROTECTED] Para comandos adicionais, envie mensagem para: [EMAIL PROTECTED]
