[Prévia] [Próxima] [Prévia por assunto] [Próxima por assunto]
[Índice cronológico]
[Índice de assunto]
Re: pull X push e java 1.4
- Subject: Re: pull X push e java 1.4
- From: PROTECTED
- Date: Fri, 22 Mar 2002 13:21:05 -0300
"para quem quer saber mais sobre MVC, leia na pagina dos próprios criadores
do termo (sun) ..."
Isto não é verdade. O MVC, e o próprio termo Model-View-Controller, foi
criado e utilizado inicialmente pelo Smalltalk-80, muito antes do pessoal
da Sun estar pensando em criar o Java....
Como o próprio excerto abaixo retirado do link
(
http://java.sun.com/blueprints/patterns/j2ee_patterns/model_view_controller/index.html
)
que você enviou diz:
"The MVC architecture has its roots in Smalltalk, where it was originally
applied to map the traditional input, processing, and output tasks to the
graphical user interaction model. However, it is straightforward to map
these concepts into the domain of multi-tier enterprise applications"
Outras informações em:
Veja por exemplo em:
http://minnow.cc.gatech.edu/squeak/1767
ou
http://www.object-arts.com/EducationCentre/Overviews/MVC.htm
[ ]'s
Paulo Eduardo
Azevedo Silveira To: Tiago <PROTECTED>
<PROTECTED.u cc: PROTECTED
sp.br> Subject: Re: pull X push e java 1.4
21/03/02 19:08
oi pessoal, roberto, nelson e tiago
em primeiro lugar, quero deixar claro que nesse caso o PULL eh MUITO pior
eficientemente do que o push, como o kon ja havia escrito no primeiro
email, e eu repeti na hora de escrever o meu email (quote: "com certeza o
pull (nesse caso) eh menos eficiente").
mas a minha opiniao eh que ele eh MUITO mais elegante, escalavel,
cutomizavel, e muitos outros bons adjetivos.
para quem quer saber mais sobre MVC, leia na pagina dos proprios criadores
do termo (sun) ...
http://java.sun.com/blueprints/patterns/j2ee_patterns/model_view_controller/index.html
e aqui tem um papo legal sobre pull vs push, voltado a web, mas vale em
varios casos:
http://jakarta.apache.org/turbine/turbine-2/pullmodel.html
e aqui vai uma boa citacao (e engracada) sobre o pull deixar a coisa mais
escalavel e customizavel que o push:
"Gone are the days where one would have a Java class that would be
responsible for building the context up for the template. Instead, there
would be a single base class that places the few objects into the context
for every request and there is a documented API that the template designer
can refer to in order to access the information that he/she needs to get
at. Of course this information is only retrieved when requested and can
also be managed in a cache for reuse.
By moving to a "Pull" model, it becomes possible to more easily achieve
complete independence from the Java engineers in order to not only change
the look and feel (UI) of the site but also the information architecture
(IA) layout and flow of the site. "
a fonte eh o link anterior, um pessoal do apache responsavel por um
framework de servlets.
falou
sao os meus 2 centavos.
paulo
---------
"The software required Win95 or better, so I installed Linux."
"Standards are good! Let us have a LOT of them!"
Paulo Eduardo A. Silveira <PROTECTED>
UIN: 5142673 www.paulo.com.br
On Thu, 21 Mar 2002, Tiago wrote:
> Nelson Posse Lago mandou bem:
>
> > Ah, mas quem disse que o servidor do chat tem que ser o seu controller?
>
> exato... Uma coisa é push/pull entre os hosts, outra coisa é o que vc faz
no
> cliente depois que a msg chegou. Eu acho que no MVC, a coisa nao é nem
push e nem
> pull: o Model avisa o View que ele mudou, e o View relê os dados do
Model.
>
> Mas essa idéia também pode se aplicar à parte cliente/servidor: se todas
as
> mensagens (por mensagens eu incluo "Tiazinha entrou na sala" e coisas do
tipo) sao
> numeradas, o servidor pode avisar o cliente que há novas mensagens, e o
cliente
> "puxa" os dados novos. Isso sim geraria uma sobrecarga maior no servidor
do que os
> dois primeiros métodos, pq inclui duas mensagens.
>
> Mas eu me pergunto: entre um pull e o próximo, qual a probabilidade de
termos
> novos dados? Gigantesca, no mínimo... no caso do chat, nao acho o pull um
método
> pior que o push... a menos que se considere que o servidor tem que
guardar as
> mensagens até todos os clientes puxarem. Hmmmm...
>
> > > no pull, basta voce deixar acessivel, que o viewer pode "pullar" o
que ele
> > > precisa / o que ele quer.
> >
> > Hmmmm, isso nao parece bom; se a nada acontecer durante 1h, o viewer
vai
> > ficar "pullando" no mesmo lugar (sem trocadilhos...) totalmente `a toa.
> > Agora, coloca 500 caras numa unica sala sem nenhum trafego e voce vai
> > gerar um load bem grande no server (e na rede!) sem necessidade. Pior:
a
> > menos que voce "pulle" rapidinho (ja' disse *sem trocadilhos!*), vai
> > sempre haver um certo atraso entre o envio de uma mensagem e o
recebimento
> > dela pelos outros.
>
> Mas quando vc usa push, vc ainda tem que saber quem ainda tá conectado! O
CORBA se
> encarrega das conexoes, mas ele nao mantém sockets abertos pra cada
cliente (ainda
> bem!). Quando ele verifica? Quando for dar push? Daí vc fica 1h
conectado, e "nada
> acontece", e de repente vc manda "alo?" e lê:
>
> "- Tiazinha saiu da sala"
> "- Johhny16 saiu da sala"
> "- ***Lili saiu da sala"
> ... todo mundo saiu da sala.
>
> esse problema acontece com todos os métodos, desde que os usuários usem
modem. Mas
> vc fica 1h sem saber que o problema aconteceu se vc usa push simples, sem
nenhum
> sistema de keep_alive.
>
> > > nao acho o push uma boa pratica de programacao para escalabilidade do
> > > VIEWER (cliente do chat) de um sistema
>
> C queria deixar só "a tela" no cliente, né?? Dá pra fazer, mas... tem
esses
> "issues"...
>
> Ia ser legal se desse pra gente misturar server de um com client de
outro, mas ia
> precisar de um padrao... acho que o professor quer que cada um crie suas
IDLs,
> né??
>
> Tudo de bom!!
> Tiago "eu sempre respondo, o que eu nao sei eu invento" Silveira
>
>