Danilo

   N�o sei se � uma falha mas, talvez, vis�es
diferentes. A Micro$oft coloca um cabresto no cavalo e
n�o de deixa muitas alternativas a n�o ser seguir seus
frameworks, suas conven��es. Isso � bom para quem est�
meio sem rumo e procura um "Porto Seguro" (pelo menos
aparentemente). A Sun deixa o cavalo livre, selvagem,
para correr para todos os lados. Hoje sou e espero
continuar livre mas, como tenho que comprar o leitinho
das crian�as, fico de olho no mercado.



 --- Danilo_Marcolin_de_Almeida_C�sar
<[EMAIL PROTECTED]> escreveu: > 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]
>  

_______________________________________________________________________
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]

Responder a