No artigo anterior, fiz uma contextualização histórica a respeito do Delphi e do surgimento do .NET, o que houve com os desenvolvedores na época (também falando sobre a minha realidade) e o que a Microsoft propôs para que os desenvolvedores abandonassem o desenvolvimento em Windows Desktop para começar algo para a Web. Mencionei também que a conversão teve um sucesso moderado. Aqui recomeço deste gancho: os acertos de erros do ASP.NET Web Forms e o que a Microsoft fez depois de 9 anos.

Da mesma forma que comecei o texto anterior, vou contextualizar minha realidade para chegar ao assunto que quero falar. Preferencialmente começando de forma muito semelhante.

O ano era 2009. Como falei no texto anterior, eu era um Analista de Sistemas, mas aqui, Júnior. Tinha acabado de ser promovido, de fato. Eu era um programador prolífico, cheio de ideias. Algumas meu chefe apoiava. Outras, se mantinha cético. Cheguei a ouvir que eu era um cara muito idealista. Tinha pouca vivência com clientes e estava aprendendo a ser mais diplomático no telefone, nos e-mails, nos contatos em geral. Na época, a empresa estava começando no ASP.NET e vendia seus primeiros sistemas nessa tecnologia. Os programadores que trabalhavam nesses projetos tinham mais visibilidade que os programadores que mantinham os sistemas legados. Quem trazia dinheiro era mais valorizado. Eu era dos sistemas legados. Tinha conseguido trazer dinheiro destravando ideias de implementação que há muito estavam engavetadas, mas meu trabalho aparecia pouco. Arrisco dizer que meu trabalho só apareceu de verdade depois que saí da empresa.

Eu tinha um colega que estudava Ruby on Rails por conta. Trabalhávamos lado a lado. Ele sempre falava como a tecnologia era maravilhosa, mas apenas isso, sem muitos detalhes. Eu estudava PHP nas minhas noites livres (sim, horrível, mas estudava, então está valendo) e fazia uns sistemas de vez em quando. Meu colega sugeriu, ao invés de começar diretamente no Ruby on Rails, passar por um framework MVC antes, sendo o CakePHP uma boa opção para começar. Baixei o CakePHP e comecei a estudar. Por mais que PHP seja uma linguagem ruim, o framework implementava bem boa parte dos conceitos MVC que foram muito importantes mais adiante.

Coisas como scaffolding, estratificação de Models, apresentação independente de formato e, sobretudo, produtividade vieram na época que estudei CakePHP. Várias soluções do framework não eram boas, mas a base foi fantástica para o próximo passo: o Ruby on Rails.

Fiz o famoso Ruby on Rails Tutorial escrito pelo Michael Hartl. Era longo, intrincado, cheio de detalhes (ainda é). O conceito de ter um gerenciador de pacotes surgiu para mim aqui. Era incrível poder confiar na ferramenta para resolver todos os emperros de atualização de componentes. Também fui apresentado ao conceito de pré-processadores (CSS e JS), carga preguiçosa e antecipada através do Active Record, variação incremental do banco de dados através do mecanismo de migrações, em que a aplicação controla o banco de dados por via de código, serialização em diferentes formatos, vários tipos diferentes de testes unitários, e então finalmente entendi a empolgação do meu colega, e ela procede. Rails foi por muito tempo o santuário das grandes ideias para a Web. Um achado.

Mas, quem usava Ruby on Rails no Brasil?

Bom, pouca gente. Era preciso ter devoção e paciência para programar em Ruby on Rails no Brasil e ser remunerado por isso (hoje já está bem melhor, felizmente). Eu tinha três opções, portanto:

  1. Investir no CakePHP e/ou outros frameworks MVC no PHP: descartei essa logo de cara. PHP nunca pagou muito bem no Brasil. Provavelmente iria arrumar um emprego pra ganhar menos;
  2. Estudar Ruby on Rails e procurar vagas em Ruby: a escassez do mercado nunca me empolgou. Trabalhar com o que se gosta é bom, mas ganhar dinheiro também é, e provavelmente eu iniciaria como Programador Júnior, que não é algo que me empolgava;
  3. Procurar um framework MVC em uma linguagem de mercado: aqui eu tinha Delphi, Java e .NET. Delphi não tinha o paradigma Web até então. Java tinha o Spring MVC e o .NET tinha o ASP.NET MVC.

ASP.NET MVC? Curioso.

Todas as minhas horas livres na frente do computador iam para estudar aquele framework, que era jovem e cheio de coisas semelhantes ao Rails. Ainda não tinha todos os recursos, mas já estava bem maturado. Havia a implementação de um framework em separado para os dados, muito semelhante ao Active Record do Rails, com o dispositivo de migrações e tudo, mas dentro da realidade do Microsoft SQL Server. Havia um mecanismo de execução de código .NET na apresentação, chamado de Razor, e, sobretudo, havia o scaffolding, que na época era experimental, mas funcionava divinamente bem, e que alguns anos mais tarde foi incorporado nativamente ao Visual Studio 2013, já na versão do ASP.NET MVC5. Comecei no MVC3.

Finalmente eu havia achado meu norte. Finalmente eu estava na toada da tecnologia de ponta. Isso foi essencial para minha vida mudar completamente, eu trocar de emprego, abrir empresa, multiplicar minha renda por 4.

Historinha contada, espero que tenha instigado o leitor à altura para esta parte 2.

Web Forms e Seus Problemas

Como eu disse na parte anterior, o ASP.NET Web Forms trazia todo um conjunto de funcionalidades que eram comuns a programadores Delphi, mas que iam contra o bom padrão de design e fluxo do HTTP, com algumas ideias como, por exemplo, a manutenção de estados da aplicação, mas era um começo. Os problemas disso não tardaram a vir.

O Inferno dos Postbacks

Cada operação de fornecimento de dados a aplicações ASP.NET Web Forms eram feitas por padrão usando POST, mesmo as que não eram formulários. Isso fez a equipe analisar a requisição e incluir um parâmetro chamado Page.IsPostBack com o intuito de verificar se a página estava vindo de um método POST para ela mesma. A ideia parecia boa no começo, mas era usada à exaustão em todo tipo de lógica bizarra que se possa imaginar. Experimente fazer uma pesquisa no Google e veja a quantidade de problemas relacionados ao Postback que são encontrados.

Sendo o padrão de método POST mais utilizado que GET, isso aumentava o caos na hora de usar Postback, gerando um sem-número de casos bizarros e fluxos imprevisíveis nas aplicações. Isso forçou os times a se adaptarem e a estudarem os conceitos e os bons padrões de design HTTP, ainda que timidamente.

Sessions

Havia também a necessidade da manutenção de vários estados, como no Delphi, responsabilidade está que foi transferida para a implementação das Sessions. Sessions até não foram tão problemáticas como o Postback, pelo menos de início. Com o início de transações distribuídas e conceitos de balanceamento de carga, isso mudou.

Sessions simplesmente não funcionam bem em ambientes distribuídos, pelo menos usando a configuração padrão. As soluções que a Microsoft encontrou foram:

  1. Montar um servidor isolado de Sessions. Aparentemente é a abordagem que melhor resolve o problema de uma forma geral, mas acarreta no uso de mais recursos de infraestrutura;
  2. Usar o SQL Server para armazenamento de Sessions. É mais complicado de usar porque todo dado precisa ser serializado (e, consequentemente, desserializado) na comunicação com o banco de dados.

Code Behind

O Code Behind é o arquivo .PAS do ASP.NET Web Forms. É um arquivo em uma linguagem do .NET que implementa os eventos disparados pela apresentação. Esse disparo é feito através de requisições para endpoints - ou seja, endereços que recebem requisições -, e que recebem informações adicionais para a execução do evento. Esse envio de informações é feito através de formulários, requisições GET ou ainda, JavaScript. Por padrão, um arquivo de Code Behind implementa apenas um endpoint.

Aqui é importante dizer que cada componente do Web Forms, no fim das contas, será a geração de HTML e JavaScript com o necessário para a chamada aos eventos escritos no Code Behind. Mas, e se queremos um comportamento que não mude o estado da tela, como um evento Ajax, por exemplo?

Resposta: não é possível fazer, a não ser instalado uma biblioteca de componentes chamada AjaxControlToolkit, que nem é mais desenvolvida pela Microsoft. Ou, ainda, o uso de Web Methods, que é só o nome bonito para expor o método do Code Behind como um endpoint verdadeiro. Aqui vem um pensamento:

Se estamos agora trabalhando diretamente com endpoints verdadeiros, não é melhor passar tudo para endpoints verdadeiros e não trabalhar mais com componentes engessados, que só geral HTML e JavaScript como resultado final?

É aqui que o ASP.NET MVC obtém seu grande triunfo sobre o ASP.NET Web Forms. Só há a opção de trabalhar com endpoints verdadeiros, preferindo não usar estados e mercadores de requisições POST. É o primeiro framework que implementa todo o ciclo existente no HTTP sem fricção.

Na terceira e última parte, vou descrever o que muda do Web Forms para o MVC, ainda traçando paralelos com o Delphi.