Mural de Rede Social Usando ASP.NET MVC - Revista .net Magazine 100 - Parte 1

O artigo trata de como criar um mural de rede social utilizando técnicas de composição de HTML no browser do cliente utilizando o padrão MVVM.

Artigo no estilo: Curso

De que se trata o artigo

O artigo trata de como criar um mural de rede social utilizando técnicas de composição de HTML no browser do cliente utilizando o padrão MVVM. Além disso, usa a biblioteca SignalR.Net para a comunicação em tempo real multiusuário com ASP.NET MVC, C# e JavaScript.

Em que situação o tema é útil

É útil em aplicações web com uma ou mais características de rede social (como notificações, atualizações, bate-papo, mural e fórum), que demandam comunicação em tempo real e atualização intensiva da interface HTML.

Como Criar Um Mural de Rede Social

Neste primeiro artigo iremos apresentar algumas bibliotecas, técnicas, ferramentas e uma aplicação web totalmente funcional que imita algumas das funcionalidades do Facebook.

Vamos utilizar o framework Fluent NHibernate para implementar o mapeamento do modelo de dados, de forma limpa e sem configurações via XML. Em seguida, criaremos cuidadosamente as views aplicando client-side composition e MVVM binding com a ajuda da biblioteca Knockout, e para deixar a aplicação com jeito de rede social vamos utilizar a biblioteca SignalR.Net para fazer todo o trabalho de “encanamento” para nossas comunicações em tempo real.

Por muitos anos, ficamos presos a um modelo onde o navegador e a web apenas eventualmente se conectam e trocam informações: isso tem muito a ver com o fato de o HTTP ser um protocolo stateless, isto é, um protocolo sem estado. Em outras palavras o HTTP interpreta a comunicação de uma aplicação web como uma sequência de pares independentes de requisições e respostas. Para o HTTP, cada nova requisição não é tratada como uma continuação da requisição anterior, mas sim como uma nova requisição. Para resolver esse problema, ao longo dos anos foram criados mecanismos de autenticação e preservação do estado da navegação, como os cookies, as sessões e os ViewStates, que passaram a ser enviados ao servidor a cada requisição, para ajudar a identificar o autor dos chamados, a sessão e o estado da página. Nesse estágio da web, toda requisição feita ao servidor era uma requisição de página completa, mesmo que a alteração fosse apenas um elemento. Tomando como exemplo um gerenciador de e-mail online, a página de caixa de entrada teria que ser totalmente recarregada para que fosse atualizada uma única linha indicando que um e-mail acabou de chegar. Com a popularização de sistemas que funcionam inteiramente na Web e também com o aumento da velocidade das conexões banda larga, o problema da espera pelo envio e retorno da página inteira se tornou muito mais evidente para o usuário.

Depois foram amadurecendo os componentes que permitiram utilizar o potencial da tecnologia AJAX, entre elas a API chamada XMLHTTPRequest, escrita em JavaScript. Cada requisição XMLHTTPRequest partia do código JavaScript e o resultado era devolvido para esse mesmo código, e então algum elemento da página era atualizado, como por exemplo, a linha contendo o e-mail novo. Com requisições mais leves, respostas com menor consumo de rede e atualização mais rápida do conteúdo das páginas, em pouco tempo os principais websites passaram a utilizar Ajax em larga escala e logo ele se tornou padrão da indústria. As principais vantagens das aplicações AJAX é que os dados enviados e recuperados pela rede são reduzidos e o usuário não precisa esperar a página ser recarregada a cada resposta do servidor. Apesar de não possuir nada inovador em sua essência, o uso de AJAX revolucionou o desenvolvimento web. Havia claramente uma necessidade de se criar uma web mais ágil e interativa, mais eficiente no consumo de dados, e com melhora significativa na comunicação entre o navegador e o servidor. Nesse ponto em particular havia o problema bastante comum em que a página no navegador não tomava conhecimento sobre atualizações importantes que ocorriam no servidor. Para isso surgiram técnicas como o pooling, onde o código JavaScript do navegador envia requisições Ajax ao servidor em intervalos de tempo regulares, para obter possíveis notificações e atualizar a página adequadamente. Embora o pooling resolvesse o problema das notificações, ele não era uma solução de tempo real, pois as atualizações não eram instantâneas e, além disso, havia o problema sério de consumo de recursos de processamento excessivos tanto do navegador quanto do servidor. Este, particularmente, sofria com o número de requisições que cresciam em progressão geométrica devido à entrada de novos usuários realizando pooling ao mesmo tempo, o que prejudicava muito e até comprometia a escalabilidade da aplicação.

Para resolver isso, tempos depois surgiram especificações HTML5 descrevendo os WebSockets, como uma tecnologia que fornece canais full-duplex de comunicação bidirecional sobre uma conexão TCP, projetada inicialmente para (mas não limitada a) navegadores e servidores web. Os WebSockets resolvem definitivamente o problema da falta de um mecanismo eficiente de conexão persistente e notificação entre cliente e servidor, porém, a tarefa de configurar um servidor para fazer uso de WebSockets pode se tornar inviável para quem trabalha com tecnologias Microsoft, já que os WebSockets são suportados somente a partir do Windows 8, Windows Server 2012 e Internet Explorer 10. Para arquitetos, analistas e desenvolvedores, isso restringe muito a configuração mínima necessária dos servidores e dos usuários para que a tecnologia WebSockets funcione.

Por esse motivo, foi criada a biblioteca SignalR.Net, que fornece toda a infraestrutura para o uso de uma conexão persistente entre o navegador e o servidor web de maneira simples de se configurar e transparente para o desenvolvedor, permitindo trabalhar com todos os servidores ASP.NET e navegadores existentes no mercado. Internamente, o SignalR.Net pode trabalhar com WebSockets , caso eles existam na infraestrutura do servidor. Caso os WebSockets não estejam presentes, o SignalR.Net irá utilizar a estratégia de long pooling. que é um mecanismo em que o código JavaScript de cada navegador estabelece uma conexão persistente com o servidor web (isto é, a conexão nunca expira) até que o servidor envie uma mensagem para o navegador. Quando a mensagem é retornada, a conexão é interrompida e então o SignalR.Net automaticamente reestabelece uma nova conexão persistente entre aquele navegador e o servidor web. Isso emula a conexão real em duas vias fornecidas nativamente pelos WebSockets. Tudo isso de forma transparente, sem que o desenvolvedor precise conhecer os detalhes desse mecanismo.

Podemos dizer que o SignalR.Net possibilita e simplifica o desenvolvimento de aplicações que fazem parte do que poderíamos chamar de “nova web”: mais dinâmica, ágil, interativa e (porque não dizer?) muito mais “social”. Sim, é importante frisar que o aspecto “social” das aplicações web não pode mais ser deixado de lado. E com “social” não queremos dizer que o usuário simplesmente tenha acesso a “joguinhos” (apesar da crescente indústria que há por trás desse negócio), mas sim explorar o lado do comportamento humano em que as pessoas buscam a comunicação com outras pessoas. Muito mais do que estabelecer conexões, a nova web permite que as pessoas se expressem, digam o que pensam, sejam ouvidas e também sejam ouvintes de outras pessoas. São novos canais de comunicação que se abrem e que agregam valor ao produto. Colocar pessoas em primeiro plano é algo que muitas aplicações web modernas almejam, pois a participação coletiva é um termômetro importante, que mede o grau de interesse e de satisfação dos usuários com relação ao produto, e que quando necessário também permite a tomada de ações rápidas com relação ao comportamento desses usuários.

Não é à toa que o aspecto “social” é o fator de sucesso de muitas ideias que rapidamente se tornaram negócios bilionários nos últimos anos: Basta olhar os exemplos do GMail, Facebook, Google Plus, Outlook.com e Twitter, que conectam usuários numa escala gigantesca e gerenciam milhões de conexões simultâneas. Veja também o que ocorre com os “jogos sociais” como FarmVille, CityVille e The Sims Social. Todos eles se baseiam num mecanismo que conecta múltiplos jogadores de diversas partes do mundo através de serviços de um mesmo "

[...] continue lendo...

Artigos relacionados