O arquivo Global.asax nos dá a possibilidade de escrever algum código para a “infraestrutura” da nossa aplicação web. Infraestrutura por assim dizer, mas na verdade, entendendo bem o ciclo de vida de uma aplicação ASP.NET, podemos implementar lá qualquer coisa que seja pertinente ao nosso projeto. Por padrão, o Visual Studio não coloca todos os métodos dos eventos que podemos utilizar no Global.asax, existem alguns muito interessantes que vale a pena conferir.

Listados na sequencia que ocorrem, segue abaixo os eventos que são disparados quando uma requisição é feita:

1. Application_BeginRequest – Disparado quando uma requisição é recebida, sendo então o primeiro evento disponível. Aqui você pode colocar algum código com a certeza de que o mesmo será executado antes de tudo.
2. Application_AuthenticateRequest – Disparado quando a identidade do usuário que fez a requisição é válida. Analisando as propriedades contidas no objeto Request, aqui você pode implementar uma lógica de autenticação para negar o acesso ao usuário caso necessário.
3. Application_AuthorizeRequest – Disparado quando o usuário teve permissão para acessar a página ou o conteúdo. Analisando as propriedades contidas no objeto Request, aqui você pode implementar uma lógica para negar o acesso a uma página ou recurso específico.
4. Application_ResolveRequestCache – Disparado quando (opcionalmente) é possível obter a resposta da requisição através de um cache, evitando que a mesma seja executada da maneira normal. Se já não estiver sendo feito automaticamente pelo IIS ou por alguma mecânica padrão do ASP.NET, aqui você pode implementar um retorno obtido através de um cache customizado, e terminar a requisição forçadamente chamando o método CompleteRequest.
5. Application_AcquireRequestState – Disparado quando a sessão do usuário foi (ou não) reconhecida e está pronta para ser usada. Aqui você fazer algum ajuste qualquer nas variáveis de sessão do usuário.
6. Application_PreRequestHandlerExecute – Disparado logo antes de iniciar os procedimentos para do processamento da requisição do usuário. Aqui você pode executar algum código tendo a certeza de que nenhuma programação responsável por devolver o que foi solicitado foi executada.
7. Application_PreSendRequestHeaders – Disparado logo antes que qualquer coisa seja colocada no cabeçalho de resposta da requisição. Desde nenhum código anterior tenha colocado algo no cabeçalho de resposta, aqui você pode executar algum código tendo em mente que nada ainda foi colocado no cabeçalho de resposta da requisição.
8. Application_PreSendRequestContent – Disparado logo antes que qualquer coisa seja colocada no corpo da resposta da requisição. Desde nenhum código anterior tenha colocado algo no corpo da resposta, aqui você pode executar algum código tendo em mente que nada ainda foi colocado corpo da resposta da requisição.
9. << A execução do seu código, podendo ser MVC, WebForms, WebAPI ou qualquer outra coisa. >>
10. Application_PostRequestHandlerExecute – Disparado logo após terminar de executar a programação da página ou recurso requisitado. Aqui você pode implementar alguma lógica que precisa ser executada toda vez que programação da página ou recurso terminar.
11. Application_ReleaseRequestState – Disparado quando toda a programação referente ao processamento da requisição é terminado. Similar ao evento anterior, aqui você pode implementar alguma lógica que deve ser executada quando as programações terminarem (chamar o Dispose de algum recurso, etc...).
12. Application_UpdateRequestCache – Disparado quando a requisição foi terminada e a mesma agora pode ser armazenada em um cache para tornar mais rápido as requisições subsequentes. Se já não estiver sendo feito automaticamente pelo IIS ou por alguma mecânica padrão do ASP.NET, aqui você pode implementar a gravação do conteúdo processado em um cache customizado para reutilizá-lo mais tarde no método Application_ResolveRequestCache.
13. Application_EndRequest – Disparado quando a requisição terminou. Aqui você pode colocar algum código com a certeza de que o mesmo será executado depois de tudo.

Legal não é? Conhecer esses eventos vai nos dar a possibilidade de resolver vários problemas de forma ágil e prática.

Mas como é a assinatura desses métodos?

Todos possuem o retorno como void e dois parâmetros de entrada, o primeiro um Object e o segundo um EventArgs, como no exemplo ilustrado abaixo:

Dica: O nível de acessibilidade fica por sua conta, pode ser protected, private ou public, tanto faz. E o nome do método não é case sensitive.

Entretanto, nem sempre é bom rechear esses métodos com muito código, pois muitas vezes vamos ter implementações genéricas que poderiam ser utilizadas em outros projetos (lógicas de autenticação ou segurança por exemplo) que acabam ficando muito acopladas no Global.asax, e dessa maneira vamos perder a possibilidade de fazer um reaproveitamento de código, fora que tudo ficará muito amontoado no Global.asax, dificultando o entendimento e a manutenção. O ideal é só implementar o que é específico desse projeto, e o genérico, colocar em módulos ou utilidades específicas do MVC ou WebForms.