Existe uma restrição comum que pode ser observada no funcionamento de quase todas as aplicações web, o que contribui para o seu comportamento sem estado. É a conexão intermitente entre o Servidor e o Cliente.

O que acontece é que, ao implementar o HTTP (Hyper Text Transfer Protocol) para comunicação pela web, um determinado padrão é seguido, conhecido como solicitação e resposta. Na verdade, esse padrão é sem estado por natureza, pois não retém o estado de nenhuma solicitação ou sua resposta correspondente. Portanto, sempre que um cliente inicia uma solicitação ao servidor da Web, o servidor da Web cria um objeto completamente novo da solicitação. Isso acaba causando interrupção na conexão e criando gargalos no desempenho.

Felizmente, o ASP.NET oferece uma ótima solução para superar esse problema com várias técnicas eficazes de gerenciamento de estado para aplicativos da Web.

Vamos refletir sobre as incríveis ofertas do ASP.NET e entender como ele ajuda a manter o estado dos controles.

Observou-se que quando o padrão de solicitação e resposta cria as viagens de ida e volta, o valor do controle do servidor é de alguma forma retalhista enquanto o valor do controle HTML desaparece. Isso ocorre porque os Controles do Servidor implementam implicitamente a técnica de Gerenciamento de Estado (View State), que permite reter os estados.

O ASP.NET oferece vários métodos brilhantes de gerenciamento de estado, todos eles destinados a diferentes aplicativos. Eles são basicamente segregados em duas grandes categorias, ou seja, gerenciamento de estado baseado em cliente e gerenciamento de estado baseado em servidor. Aqui está uma breve introdução a várias técnicas.

Gerenciamento de estado baseado no cliente

Nesta abordagem os dados são armazenados na máquina do cliente ou na página sem envolver os recursos do servidor. Esses dados armazenados incluem todas as informações relacionadas à interação entre o cliente e o servidor. Como os dados são armazenados no lado do cliente, eles ficam mais vulneráveis ​​a hackers, tornando as técnicas menos seguras e mais escaláveis.

Com esta abordagem, o ASP.NET facilita os métodos abaixo mencionados:

1) Ver estado:

Este método de nível de página ajuda a armazenar as informações sobre uma página específica até que ela esteja ativa. Ou seja, assim que o usuário redirecionar para outra página, todas as informações armazenadas desaparecerão. Isso ajuda a manter o estado no nível da página. Nesta técnica, os dados são armazenados na forma de objeto de dicionário (no par de uma chave e valor). Todas as informações são armazenadas em formato hash na própria página, mas dentro de um campo oculto. Ele pode consumir um valor de string, mas apenas até um certo, se o valor exceder, outro campo oculto será consumido.

Com o ASP.NET, o estado de exibição é o método padrão seguido para armazenar o estado de aplicativos da web. É bastante simples de implementar e é ideal para ser utilizado quando um usuário é redirecionado para a mesma página, e por isso precisamos manter a informação persistente até que ele mesmo redirecione para alguma outra página.

Prós de usar o estado de exibição:

• Proteja as informações armazenadas do leigo, armazenando-as no formato hash. Na verdade, para mantê-lo protegido contra hackers, você pode manter as informações em um formato criptografado.
• Você pode personalizá-lo como e quando desejar.
• É uma ótima opção onde você deseja implementar vários postbacks em uma única página da web.

Contras de usar o estado de exibição:

• Não é uma abordagem segura, portanto dados confidenciais não podem ser armazenados com ela.
• Pode causar problemas de sobrecarga ou aumentar o tempo de carregamento, tornando a página pesada com muitas informações.

2) Biscoitos:

Oferece grande facilidade de customização do lado do cliente, pois os cookies são armazenados na memória durante a sessão do navegador do cliente ou no sistema do cliente. Na verdade, pode-se até armazenar as informações relacionadas aos usuários e rastrear o uso. Possui um pequeno arquivo de texto com tamanho máximo de 4096 bytes, sendo que uma máquina cliente pode exibir no máximo 300 cookies, enquanto um domínio ou servidor pode suportar no máximo 20 cookies.

Os cookies são ainda divididos em duas categorias, a saber:

Cookie persistente – Este tipo de cookies tem um prazo de validade e ficam permanentemente guardados no disco rígido disponível na máquina do cliente. Se não houver data de expiração correspondente ao cookie persistente, ele será considerado um cookie transitório ou não persistente.

Cookie não persistente ou cookie transitório – Como esse tipo de cookie é armazenado na memória do navegador no final do cliente por um período de tempo temporário, após esse tempo específico o cookie será perdido.

Prós de usar Cookies:

• Ele consome apenas alguns bytes de memória por cookie.
• Fácil e bastante simples de usar.

Contras do uso de Cookies:

• Ele não oferece uma abordagem segura, pois armazena as informações na máquina do cliente e, portanto, armazenar dados confidenciais não é uma escolha viável.
• Qualquer usuário pode desabilitar os cookies fazendo ajustes apropriados nas configurações do navegador.

3) Campos Ocultos:

Este é basicamente um controle de servidor, que ajuda a gerenciar o valor em nível de página e é um pouco semelhante a um View State. Seu valor é enviado via HTTP Form Collection e junto com ele também é enviado o valor de outros controles.

Prós de usar campos ocultos:

• É bastante simples de usar.
• Como o valor é armazenado apenas na página, os recursos do servidor não são usados. Assim, os Campos Ocultos economizam os recursos do servidor.

Contras de usar campos ocultos:

• Se vários Campos Ocultos forem implementados em uma página, isso acabará por adicionar peso à página e torná-la mais volumosa e, assim, aumentar o tempo de carregamento da página.
• Essa abordagem não é ideal para armazenar os dados confidenciais. Como não armazena os dados em formato criptografado ou hash, essa técnica não é totalmente segura.

4 Estado do Aplicativo:

Este estado é perfeito para armazenar os dados que devem ser acessados ​​em todo o aplicativo. Ocupa os recursos do servidor, pois armazena os dados na memória do servidor. O estado Aplicativo não se limita a nenhum usuário ou sessão em particular, mas é aplicável a todas as sessões e usuários. No entanto, neste caso, os dados serão retidos apenas enquanto o aplicativo estiver em execução, assim que o aplicativo for encerrado ou reiniciado, todos os dados armazenados serão perdidos. Na verdade, ele também será desperdiçado quando um servidor da Web for reiniciado, pois os dados são armazenados no final do servidor.

No Application State, um objeto da classe HttpApplicationState é usado para armazenar os dados. Essa classe é uma coleção de objetos nomeados, o que significa que ela inclui os dados de qualquer tipo. Pode ser parte de um par chave/valor.

Prós do estado de aplicação:

• O Application State tem escopo global. Os dados podem ser acessados ​​a qualquer momento quando o aplicativo estiver em execução.
• Não há período de expiração por padrão.

Contras do estado de aplicação:

• O estado do aplicativo requer recursos do servidor para armazenar dados. Isso pode levar a problemas de escalabilidade se não for tratado adequadamente.
• Application State não é thread-safe, então precisamos implementar Locks.
• No caso de falha ou reinicialização do aplicativo, todos os dados armazenados são perdidos.

5 Estado da Sessão:

Esse método é mais comumente usado por vários desenvolvedores para manter o estado do aplicativo. Nessa abordagem, o valor é armazenado na forma de coleção de dicionário, ou seja, é emparelhado como chave e valor. Aqui os recursos do servidor são totalmente usados ​​para armazenar o estado do aplicativo. Como o armazenado não é repassado aos clientes, essa técnica oferece um método seguro e altamente seguro.

Nessa abordagem, uma sessão separada com um ID exclusivo é gerada para cada usuário. Como este ID é salvo no sistema do cliente, são utilizados cookies para seu armazenamento. A sessão é eliminada assim que o usuário faz logout do aplicativo e, se ele retornar ao aplicativo no futuro, uma nova sessão será criada.

Pode ser usado em qualquer um dos quatro modos. Aqui estão os modos:

• OFF – Para desativar a sessão, ou seja, se você não tem interesse em incluir o estado da sessão em seu aplicativo, você pode configurar no modo OFF.
• InProc – As variáveis ​​de sessão são armazenadas neste modo por armazenamento padrão. Aqui, o valor é armazenado no mesmo processo em que o aplicativo ASP.NET está realmente sendo executado. Assim, oferece excelente desempenho.
• State Server – Neste modo, os dados são armazenados em um processo separado dentro do Windows Service. Assim, isola os dois processos, um onde o aplicativo está sendo executado e o segundo onde os dados são armazenados. Portanto, seu desempenho não é tão bom quanto no modo InProc.
• SQL Server – Aqui os dados da sessão são armazenados no SQL Server. É difícil gerenciar no modo InProc com várias máquinas servidoras. Para isso, é melhor armazenar os dados apenas no servidor SQL, isso tornará os dados acessíveis centralmente para todas as máquinas. Este modo oferece segurança máxima, no entanto, oferece desempenho degradado.

Essas cinco são as técnicas de gerenciamento de estado mais comumente usadas para aplicativos ASP.NET. Integre essa técnica em seu aplicativo que pode garantir total segurança aos dados e desempenho rápido.