Vou focar no Flex pq é o que conheço
Como diria Jack, vamos por partes
[quote=luizSC]Pessoal,
Nas interfaces web que tenho desenvolvido, fico com a impressão que mesmo quando se tem a disposição frameworks que permitem a construção de clientes ricos (GWT, FLEX) é, na maioria dos casos, vantajoso manter-se dentro da filosofia thin client.
Observo que enviar a entrada do usuário bruta (strings e tipos primitivos) para o backend e em seguinda, delegar o tratamento a um POJO independente da tecnologia de GUI tem, entre outras, as seguintes vantagens:
[/quote]
Com Flex vc pode mandar as propriedades como primitivos sem problemas, pode usar webservice, pode fazer chamada http numa boa. Agora o pessoal usa mais chamada remota pq é bem mais fácil. Se comparar com Webservice, a chamada AMF é bem menor, pq não vai um xml todo, e sim o binário do AMF.
Depende do que seu cliente vai fazer. Se o forte for a interatividade, as coisas saem bem mais fácil que no html. Além disso, a criação de componentes e bibliotecas é muito fácil tb.
Também para acelerar o lado do cliente depende do programador. Eu sei infinitamente mais Flex que HTML, então pra mim, é muito mais rápido fazer em Flex. E pelo que tenho visto dos desenvolvedores da empresa que trabalho, a produtividade tem sido muito maior em flex mesmo. Vc realmente possui um debuger a nível de tela, coisa que os pseudo debuggers de html nem chegam perto.
Além disso, com cliente gordo consigo fazer protótipos interativos, que respondem ao cliente sem acessar o servidor, melhorando o processo de análise ainda durante a fase de design, o que economiza tempo de desenvolvimento. Em HTML isso fica um pouco mais complicado.
Concordo parcialmente se estivermos falando de rodar o Flex no browser. Isso pq se o swf ficar no cash, pode ser que demore menos. E se for usar o Adobe Air, plataforma desktop do Flex, aí isso já cai por terra, já que toda a “view” já estar no cliente e não precisar haver download algum, apenas chamadas de dados aos servidor. Com a vantagem de que se o cara programa em Flex, programar em Air é igual, só acrescentam algumas bibliotecas de acesso à máquina do cliente, drag nativo, entre outras coisas
Concordo plenamente. Quem é novo em flex passa classes de domínio pra ele, e depois acaba se lascando com problemas de performance e lazyException. Infelizmente ainda não vi outra saída além de fazer uma camada DTO pra um sistema com cliente gordo.
Verdade, mas nunca senti desvantagem. Se o obj vem com ID e vc faz a segurança dele, usar um makePersistent + “open session in view” da vida faz vc nem meditar sobre a questão
[quote]
Como o tratamento no server (handler) é implementado num POJO, pode-se utilizá-lo com diferentes tecnologias de Clients (utilizar o mesmo handler para JSF, GWT e Flex)
…
A desvantagem, logicamente é a quantidade de requisições feitas entre o client e o server, mas na prática, não tenho observado perdas em função disso, até porque são requisições assíncronas.
Esta desvantagem pode ainda ser minimizada com a implementação de um Binder, no client, capaz de realizar a atualização de uma tela inteira numa única requisição ao server.
Agradeceria se pudesse contar com a valiosa opinião dos colegas a respeito das considerações acima.
Abraços[/quote]
Vejo outras desvantagens:
Incompatibilidade entre browsers, e ActionSript estar mais próximo do desenvolvedor que HTML
Então, minha opinião hj é a seguinte: aplicação no browser, prefiro html. Aplicação desktop com chamada na web, Adobe Air mata a pau (veja o Revelação Virtual onde eu precisei acessar recursos da máquina do cliente). Mas essa é minha opinião estritamente pessoal.
A verdade é que cada caso, é um caso, com vários fatores a se pesar, como expertise do time com a tecnologia, natureza da aplicação e etc.
Como sempre, concordo com o sábio, que não lembro o nome, que disse “there is no silver bullet”.
Espero ter contribuido.