ASP.NET – O paradigma do ViewState
Um dos problemas mais reportados no âmbito do ASP.NET é o ViewState, i.e., os problemas relacionados com o seu uso e os problemas que surgem quando o mesmo é desligado.
É bem verdade que o ViewState pode atingir uma dimensão ridiculamente elevada e afectar o desempenho da aplicação mas não podemos esquecer os seus beneficios.
O ViewState surgiu como resposta ao pedido da comunidade para criar um mecanismo infraestrutural de persistência de estado da aplicação.
Se nos recordarmos do tempo em que faziamos ASP, uma das preocupações mais comuns era a manutenção do estado da aplicação para permitir encadear correctamente as regras de negócio.
Ora o ViewState criou uma abstracção sobre o estado. Se o ViewState estiver activo os controlos Server-Side conseguem reagir à mudança e disparam eventos. Foi esta abordagem Event-Driven que revolucionou a forma de fazer aplicações Web.
Para além disto, uma das preocupações que tinhamos (e ainda temos) era a segurança do estado. O ViewState podendo, “Out-Of-The-Box”, ser encriptado também nos resolve este problema.
Dito isto, parece óbvio que o ViewState não nasceu fruto do acaso e permitiu agilizar o desenvovimento de aplicações Web.
Então qual a razão de ser tão frequentemente usado como desculpa para justificar o não uso do ASP.NET?
Bom, a meu ver, existem vários factores que contribuem para esta situação:
- documentação pobre
- alteração de paradigma
Na verdade, julgo ser a combinação das duas. Quando nos encontramos fora da área de conforto e não conseguimos de uma forma célere respostas às nossas questões acabamos naturalmente por criar uma barreira e evitamos repetir o cenário.
Compreender o ViewState implica conhecer os segredos do ciclo de vida da página e a forma como os controlos estão envolvidos na mesma e este conhecimento não é trivial, está disperso e nem sempre é facil de estabelecer as pontes.
Ainda assim, com empenho e persistência q.b. não é dificil compreender o conceito, a implementação, as suas virtudes e acima de tudo os seus defeitos.
Atingido este ponto é possivel, contrapor e ultrapassar a maioria das limitações apontadas ao ViewState.
Através:
- da alteração ao meio de persistência do ViewState – passar da serialização para HTML para persistência em BD ou outros
- do desligar do ViewState dos controlos Bindable (GridView, DropdownList) sem que o controlo perca funcionalidade
- da redução a quantidade de informação persistida no ViewState por cada Controlo
é possivel reduzir a dimensão total do viewstate para valores razoaveis ou mesmo desprezaveis.
No ASP.NET 2.0 foi introduzido o conceito de ControlState, i.e., o estado minimo que o controlo precisa para poder reagir à mudança. Este estado não é passivel de ser desligado mas é por definição muito menor que o ViewState.
Com esta introdução pensar-se-ia que podiamos desligar o ViewState de qualquer controlo que os eventos de mudança continuariam a funcionar … mas não … o ControlState é apenas usado por um grupo reduzido de controlos e na prática o modelo Event-Driven “Out-Of-The-Box” do ASP.NET continua a depender do uso de ViewState.
Mas não desanimem, é muito facil extender os controlos para usar este conceito e desligar o ViewState sem impactos colaterais. Num próximo post falarei sobre o ControlState e sobre os cenários que descrevi.