Alias acho que essa � uma falha da SUN em rela��o a tecnologia Java, n�o dar prioridade a nada, e na minha opini�o isto � o que vai fazer tecnologia da MS ganhar espa�o sobre o Java, at� porque tenho conversado com um pessoal e parece que est� sendo muito mais f�cil pra profissionais que n�o tinham contato com nenhuma das tecnologias, iniciar j� de um bom n�vel em .Net, do que em Java.
-----Mensagem original----- De: Robson Luis Ferreira [mailto:rlsferreira@;yahoo.com.br] Enviada em: quarta-feira, 30 de outubro de 2002 10:07 Para: [EMAIL PROTECTED] Assunto: Re: RES: [enterprise-list] CMP ou BMP Pessoal T� pegando fogo essa thread !!! J� foram citadas v�rias op��es para a camada de banco de dados - BMP, CMP, DAO, JDO -, cada qual com suas vantagens e seus defeitos. Se existisse uma f�rmula perfeita vcs n�o acham que todos n�s usar�amos, a SUN daria prioridade total para ela, n�o haveria discuss�es a esse respeito, estar�amos todos felizes, a fome no mundo acabaria, etc., etc., etc. ?? Acho que cada caso � um caso, e n�o h� como definirmos um padr�o sem antes estudar as necessidades, infra e padr�es do projeto e do cliente e nossa pr�pria seguran�a em desenvolver com qualidade e prazos satisfat�rios, e pessoalmente eu tenho minha opini�o (DAO quase sempre) e cada um tem a sua. Algu�m duvida disso ? Robson Luis Ferreira [EMAIL PROTECTED] --- Antonio Kantek <[EMAIL PROTECTED]> escreveu: > > ----- Original Message ----- > From: <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Wednesday, October 30, 2002 8:57 AM > Subject: Re: RES: [enterprise-list] CMP ou BMP > > > "Antonio Kantek" <[EMAIL PROTECTED]> wrote on > 29/10/2002 14:21:04: > > > 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 ? > > Isso foi feito de proposto. Um finder no EJB n�o > deveria devolver muitos > objetos pois impacta muito no performance (uso de > memoria etc). LIKE > tipicamente devolve muitos registros do DB e por > isso foi deixado fora da > especifica��o. > > Sim, mas por isso que eu digo que as pessoas que > fizeram a especifica��o s�o > autistas. > Se essa preocupa��o realmente fosse v�lida, a > JBossQL com seu LIKE > paramatriz�vel n�o > faria tanto sucesso. > > > 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. > > CMR � bom e � ruim, como j� foi dito nesta > discuss�o. O que pode ser feito > com CMR en EJB 2.0 j� fiz tamb�m com CMP 1.1. Em > termos de modelagem n�o � > t�o complicado. > > Complicado n�o �. Mas tamb�m n�o � nada elegante. > > > > > --------------------------------------------------------------------- > 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: [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]
