Olá pessoal, dando continuidade aos artigos técnicos e sobre minhas opiniões pessoais, voltei a trabalhar recentemente com .NET para Web, porém como de costume sempre opto pelo Castle Project, a empresa que estou atualmente possui toda sua base sobre um legado de ASP 3.0, a minha função é auxiliar na migração para esse novo ambiente mas com o toque de qualidade e boas práticas no desenvolvimento e isso o Castle Project me propõe, WebForms não.

Isso não quer dizer que abandonei o Ruby on Rails, ainda continua sendo minha linguagem e framework preferidos e prometo criar mais screencasts, porém não tive oportunidades de trabalho, o mercado ainda está muito difícil para essa tecnologia e ninguém pode viver de paixões correto? :-)

Também não quero criar apenas um post para causar FUD entre os leitores, o grande motivo que resolvi escrever novamente sobre esse assunto, é que recebi a edição nº 7 da revista Mundo.NET e o artigo da capa “WebForms vs MVC – Uma análise de WebForms com Monorail e o novo ASP.NET MVC”, me chamou muita atenção, lendo o artigo concordo com cada palavra escrita ali, o Webforms está caminhando para extinção, mesmo com a idéia da MS de manter a compatibilidade com seu enorme legado, vamos aguardar como vai ser a aceitação no mercado pelo ASP.NET MVC, já que tantos desenvolvedores de WebForms (diga-se de passagem “arrastadores de componentes”), sofrem uma resistência enorme em aceitar novos paradigmas.

Antes de continuar, alguns parágrafos são da própria revista e outras algumas opiniões minhas.

O que defini um framework eficiente para os dias atuais?

Hoje em dia muito se fala em Frameworks para desenvolvimento ágil (Rails e Django), mas quais suas verdadeiras vantagens? De acordo com os argumentos da própria revista:

• Testabilidade: a medida de quão amigável a criação de testes unitários o framework é.
• Manutenibilidade: a facilidade de se dar manutenção no código, adicionando ou modificando as funcionalidades existentes.
• Extensibilidade: a facilidade de um framework integrar com outras ferramentas e de ampliar as funcionalidades oferecidas.

Recapitulando a história, o que é WebForms?

O WebForms foi o sucessor do ASP como plataforma para o desenvolvimento Web. A nova plataforma prometia:

• Uma grande quantidade de server controls para gerar HTML de acordo com o navegador do cliente.
• Um eficiente sistema de data binding.
• Código compilado
• Separação da lógica de apresentação da lógica da negócio.
• Event Based Programming, como o Visual Basic.
• Representação server side para os controles HTML.

Enfim a Microsoft foi ambiciosa com essas promessas, oferecendo um ambiente semelhante ao ambiente Desktop, assim como o Visual Basic.

Na minha opinião, quando conheci o ASP.NET, achei interessante esse novo paradigma, mas o preço veio depois. Sabemos que a Web não é um ambiente statefull e emular esse tipo de ambiente abstraindo vários fatores do desenvolvedor sempre acaba em problemas.

E esses problemas são exatamente pelo grau de complexidade que é o funcionamento interno do ASP.NET, a grande que reclamação que acontece hoje em dia é em torno do Lifecycle, apenas para ilustrar um exemplo:

Sim é ridículo esse código, mas o que acontece por baixo dos panos? O ASP.NET executa uma seqüência de eventos nessa ordem (Page Request -> Start -> Page Initialization -> Load -> Validation -> Postback Event Handling), enfim não vou descrever cada um deles, leia na revista para saber mais detalhes ok? :-)

Outro fator negativo é a testabilidade da página, afirmo que é impossível criar testes unitários para o Code-Behind, e quem trabalha diretamente com TDD, a impossibilidade de testar algum elemento da aplicação causa grandes preocupações.

Viewstate seu pior inimigo

O Viewstate é responsável pelo tráfego entre cada PostBack e também manter o estado dos componentes. A decisão de armazenar os dados serializados em um input escondido na página é muito questionável, segue alguns pontos desfavoráveis.

• Possível brecha de segurança: os dados podem ser alterados por usuários maliciosos.
• Aumento do tráfego na rede: caso o Viewstate esteja armazenando muitos dados, ele será um grande overhead para a página.

SoC – Separation of Concerns

Esse é o erro mais comum em qualquer aplicação ASP.NET, talvez pela falta de conhecimento técnico em Design Patterns ou mesmo pela pressão de entregar o projeto dentro do prazo, o desenvolvedor acaba desenvolvendo sua lógica e acesso a dados praticamente inteira dentro do Code-Behind.

Databind

O Databind é o processo de sincronização de dados entre dois modelos diferentes, como o modelo de objeto de negócios e controles html e vice-versa.

Ter um sistema de Data Binding eficiente é um ponto-chave na produtividade de qualquer framework, a proposta da Microsoft ficou bastante simples e intuitivo, entretanto, o WebForms não realiza o binding na direção oposta, ou seja, do client para o servidor, cabe ao desenvolvedor realizar toda essa tarefa no braço e sujeita a erros.

MVC (Model View Controller) é a solução?

O MVC é um design pattern que tem como objetivo principal separar “Apresentação” de “Dados”, dividindo a aplicação em três partes fundamentais: Modelos, Views e Controllers (modelos, apresentação e controladores).

• Model: representação dos dados e dos estados da sua aplicação.
• View: responsável pela lógica de apresentação de dados da interface com usuário.
• Controller: ponto principal do pattern, contendo lógica que manipula o modelo e escolhe a view que será renderizada.

Um fato interessante que a revista aborda e que também concordo é que o ASP.NET não se enquadra nesse modelo como muitos acham, sendo o code behind o controlador e o aspx a apresentação. A função do controlador está diretamente entre o aspx e o codebehind.

Monorail e ASP.NET MVC

O Monorail que faz parte do Castle Project desenvolvido desde 2003 é um framework MVC maduro construído especialmente para ambientes Web. Ele foi inicialmente inspirado pelo Ruby on Rails ActionPack, mas sem a mesma pretensão de ser um porte. Utilizando todo o poder do .NET, tornou-se um framework de sucesso e com boa aceitação pela comunidade (no exterior) por ser estável e muito produtivo. Já o ASP.NET MVC é a resposta da Microsoft a um pedido antigo: uma alternativa ao WebForms, o primeiro release público foi feito no início de Dezembro de 2007 e tem causado muita polêmica desde então.

O que nos resta saber é qual vai ser a reação das pessoas envolvidas que mantém Castle Project, se o projeto vai descontinuar, ou se teremos uma competição saudável entre as duas plataformas. Realmente não tenho um favorito, já fiz testes no ASP.NET MVC juntamente com o LINQ e fiquei impressionado pela qualidade do código final. A grande questão é que finalmente a Microsoft “enxergou a luz no final do túnel”.

Controllers

Como dito anteriormente, o Controller é a principal figura dentro do padrão MVC, seu papel é comandar o fluxo da aplicação. Num breve exemplo segue duas implementações tanto do MonoRail como do ASP.NET MVC.

Muito legal, ambas herdam uma classe Controller, porém o ASP.NET MVC obriga você definir suas Actions com o atributo ControllerAction, o motivo dessa implementação é ter a capacidade de implementar métodos privados na própria classe, o Monorail não oferece essa capacidade, pois cada método é uma Action do controlador.

DataBinding

Esse recurso é suportado tanto pelo Monorail quanto pelo ASP.NET MVC, a novidade é que ele simplifica o desenvolvimento e diminui a eventuais erros de programação, apoiando-se de uma ajuda do framework para o preenchimento dos objetos ou ligação automático dos dados da requisição com os parâmetros da action.

Segue um breve exemplo:

Para enviar os dados do formulário para o servidor seria necessário.

Se você prestar atenção, vai me questionar que caímos na mesma armadilha de preencher os dados manualmente. Para evitar esse problema o MonoRail oferece uma alternativa mais inteligente, podemos fazer que nossa classe extenda de SmartDispatcherController.

Com o uso do SmartDispatcherController não é mais necessário requisitar os dados manualmente, existem outras integrações mais interessantes para instância de objetos utilizando o atributo [DataBind].

Considerações Finais

O WebForms mostrou-se ao longo dos anos, ser um framework de difícil manutenção e extensibilidade, mas isso se da pelo fato dos desenvolvedores Web para .NET nunca terem outras opções por um bom tempo. Por outro lado, por ter uma gigantesca comunidade de desenvolvedores fazendo uso de WebForms, assim como existe uma gama de material didático, o WebForms sempre foi de uma maneira geral, bem aceito. Ele atende às necessidades tanto de projetos pequenos até os mais complexos.

Já o MVC que é um padrão bastante antigo e utilizado por vários frameworks e linguagens, oferece uma clara separação de responsabilidades entre diferentes e fundamentais camadas de uma aplicação, seja ela Web ou Desktop.

Durante um certo tempo o MonoRail parte integrante do Castle Project era a opção mais atraente entre frameworks MVC para .NET e isso gerou uma grande cobrança em cima da Microsoft para criar a sua própria versão. Tanto o Monorail ou o ASP.NET MVC existem para tornar o desenvolvimento de aplicações Web algo mais limpo, fácil e sucinto.