O que o AJAX.NET não tem?

 

Vale a pena utilizar o AJAX.NET da Microsoft ou construir a própria biblioteca AJAX?Já coloquei muito a mão na lama, mas depois de algum tempo, você passa a gerenciar projetos ou tocar uma empresa e perde o contato com os detalhes das coisas.

Por outro lado é necessário tomar decisões tecnológicas que irão afetar a empresa onde você trabalha. Estive nessa situação há alguns meses. Ir de AJAX.NET ou desenvolver uma biblioteca AJAX própria?

Pedi uma análise e uma indicação para dois dos engenheiros de software da nossa empresa sobre a proposta da Microsoft. Eis aqui o relatório.

Problemas do ASP.NET

Tudo começou quando a Microsoft introduziu o ASP.NET, uma versão aprimorada do ASP. Ela adicionou a arquitetura .NET uma tecnologia para produção de páginas web, os WebForms. Com eles se pode criar uma interface visual com o usuário de forma semelhante à feita usando o Visual Basic. A sua arquitetura é baseada no servidor.

Para criar uma página ASP.NET você tem a disposição os HTMLControls, que não são processados pelo servidor quando o usuário interage com os mesmos, e os WEBControls, que são processados pelo servidor quando existe interação.

Ao abrir uma página ASP.NET, o cliente (navegador do usuário) exibirá o resultado HTML/JavaScript de um WebForm processado pelo servidor. Quando o cliente interagir com a página, ela será transmitida de volta ao servidor, alterada e depois restaurada de volta ao cliente. E sempre que ocorrer uma interação do usuário com um controle que disparar um evento, este caminho será seguido, do cliente para o servidor e de volta ao cliente. Deu-se a isto o nome de postback.

Nessa arquitetura, o cliente é “burro” e 100% da lógica de negócio fica a cargo do servidor. Do ponto de vista do desenvolvedor isso é ótimo, facilita o desenvolvimento com a utilização dos WebControls. Mas e o usuário, onde fica?

Assim, para cada interação complexa existe um postback e para cada postback um tempo de espera. Você provavelmente estará destruindo a usabilidade de seu site e a paciência de seus usuários.

Em um exemplo simples, basta imaginar um formulário com quatro combos encadeadas e algumas validações. A página executará no mínimo quatro postbacks. A página inteira irá quatro vezes para o servidor e retornará ao cliente. Haja paciência.

Solução aos postbacks?

O modelo ACSC (Asynchronous Client/Server Communication) é muito mais interessante para o usuário que o modelo WebForm/Postback do ASP.NET e abre um leque de possibilidades de interação antes impraticáveis.

O amadurecimento e a consolidação das tecnologias ACSC (e a popularidade da implementação desse modelo com o AJAX), onde o recarregar de páginas inteiras é substituído por requisições assíncronas do cliente ao servidor e atualização somente da parte onde ocorreu interação com o usuário, obrigou a Microsoft a atualizar sua arquitetura para suportar o modelo ACSC, de modo a evitar que o ASP.NET não perdesse seu mercado.

Para manter a compatibilidade com códigos já existentes em ASP.NET 2.0, a Microsoft desenvolveu parte do Atlas baseada em sua antiga arquitetura, a centralizada no servidor (Server centric), onde o comportamento de postback dos WebControls é modificado, mas ainda assim a lógica do negócio fica toda no lado servidor. Isso é contrário ao verdadeiro modelo ACSC, onde a lógica do negocio é dividida entre o cliente e o servidor e centralizada no cliente (Client centric).

O Atlas Server Centric é baseado em painéis Ajax onde é possível inserir os WebControls já existentes do ASP.NET. Uma vez dentro do painel Ajax o postback do WebControl será substituído por uma requisição assíncrona ao servidor. O modo centralizado no servidor é na verdade apenas uma “maquiagem” para as páginas ASP.NET, já que toda lógica de negócio fica no servidor.

Nenhuma inteligência complexa é mantida no cliente. Todos os postbacks continuam sendo realizados por baixo da “máscara” do XMLHttpRequest e, como todos os WebControls ainda continuam sendo processados no servidor, o retorno do Atlas Server Centric é HTML (AJAH – Asynchronous JavaScript and HTML) e não AJAX.

Isso torna o overhead e o trafego muito maiores já que ao invés de retornar uma estrutura apenas com os dados relevantes o Atlas Server Centric retorna os dados em conjunto com HTML.

Decisão: nossa Biblioteca vs. Atlas

Tomamos a decisão de construir uma biblioteca própria para diminuir o overhead de transmissão de dados – já que isso é crítico -, a serialização e os recursos encapsulados para facilitar realmente a vida do programador. Criamos a Naja.NET.

O Atlas Client Centric tem uma arquitetura muito parecida com o framework Naja.NET. Segue o mesmo modelo, porém o Atlas Client Centric é um framework sem todos os recursos do Naja.NET, sem toda a extensão do JavaScript e sem todos os objetos portados do .NET que o framework Naja.NET possui.

A falta de serializadores e conversores de tipos complexos (como DataTable, XmlDocument, etc.) também é uma desvantagem do Atlas Client Centric em relação ao Naja.NET, que consegue converter praticamente qualquer tipo do .NET para qualquer tipo do JavaScript.

A serialização do Naja.NET também tem a vantagem de ser mais inteligente e com maior desempenho. Conforme o problema o framework escolhe entre a serialização JSON (JavaScript Object Notation) ou o retorno puro de JavaScript. Outra grande vantagem do Naja.NET é o suporte ao Framework .NET 1.1 e 2.0. O Atlas suporta apenas o framework 2.0.

A extensão do JavaScript padrão também é superior no framework Naja.NET, e conseqüentemente facilita a vida do desenvolvedor que não precisará estender o JavaScript por conta própria para atender suas necessidades e nem utilizar bibliotecas de terceiros que podem apresentar problemas de compatibilidade.

* Otávio Medeiros Dias e Marcell Dietrich Felipe Duran são engenheiros de software da Voxel Informática e colaboraram com os dados relevantes desta coluna.

Nivaldo Foresti é programador há 30 anos, desde a jurássica era do mainframe. Foi consultor e desenvolvedor de produtos na internet como o BOL e hoje tem uma empresa de webcasting, com software nacional. Neste espaço, o colunista revela o que os desenvolvedores podem esperar da profissão, além de analisar as novas eras tecnológicas que se aproximam. E-mail: nforesti@yahoo.com .

 


Anúncios

Deixe um comentário

Faça o login usando um destes métodos para comentar:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google

Você está comentando utilizando sua conta Google. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s