1. O pipeline de middlewares
Toda requisição HTTP atravessa uma cadeia de componentes antes de chegar num Controller — o pipeline de middlewares. Cada middleware pode inspecionar/alterar a requisição, decidir passar adiante ou interromper, e fazer algo com a resposta no caminho de volta.
Fig. 1 — Cada middleware decide se (e como) passa a requisição adiante — a resposta atravessa a mesma cadeia de volta.
var app = builder.Build();
app.UseExceptionHandler("/Erro"); // captura exceções de tudo que vem depois
app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseRouting();
app.UseAuthentication();
app.UseAuthorization();
app.MapControllerRoute(
name: "default",
pattern: "{controller=Home}/{action=Index}/{id?}");
app.Run();
A ordem de app.Use...() importa e é executada sequencialmente.
UseAuthorization() antes de UseAuthentication(),
por exemplo, tentaria checar permissões antes mesmo de saber quem é o usuário — um erro comum de
configuração.
2. Escrevendo um middleware customizado
app.Use(async (context, proximo) =>
{
var cronometro = Stopwatch.StartNew();
await proximo(); // passa adiante no pipeline
cronometro.Stop();
Console.WriteLine($"{context.Request.Path} levou {cronometro.ElapsedMilliseconds}ms");
});
proximo() (o parâmetro next) é o que
conecta este middleware ao próximo da cadeia — sem chamá-lo, o pipeline para ali, e nada depois
dele (incluindo o Controller) chega a executar.
3. Filters — interceptando no nível do MVC, não do pipeline inteiro
Filters atuam num nível mais específico: em volta da execução de uma Action (ou Controller), não de toda requisição HTTP. Os quatro tipos mais comuns:
| Filter | Quando roda | Uso típico |
|---|---|---|
IAuthorizationFilter | Antes de tudo — checagem de permissão | [Authorize] |
IActionFilter | Imediatamente antes/depois da Action | Log, validação cruzada, cache de resposta |
IExceptionFilter | Quando uma exceção não tratada escapa da Action | Tratamento de erro centralizado |
IResultFilter | Antes/depois do resultado (View/JSON) ser gerado | Compressão, cabeçalhos customizados |
public class LogarExecucaoFilter : IActionFilter
{
public void OnActionExecuting(ActionExecutingContext contexto)
=> Console.WriteLine($"Entrando em {contexto.ActionDescriptor.DisplayName}");
public void OnActionExecuted(ActionExecutedContext contexto)
=> Console.WriteLine($"Saindo de {contexto.ActionDescriptor.DisplayName}");
}
// aplicado a uma Action específica
[ServiceFilter(typeof(LogarExecucaoFilter))]
public IActionResult Detalhes(int id) { ... }4. Middleware vs. Filter — quando usar cada um
| Middleware | Filter | |
|---|---|---|
| Escopo | Toda requisição HTTP, mesmo fora do MVC | Só requisições que chegam a um Controller/Action MVC |
| Acesso ao ModelState/ActionContext | Não | Sim |
| Uso típico | Autenticação, HTTPS, arquivos estáticos, log genérico | Autorização por Action, validação, tratamento de exceção específico do MVC |
5. Onde isso te leva
Com o pipeline inteiro mapeado — middlewares, DI, filters — o último capítulo deste módulo junta tudo num projeto prático completo, ligando de volta ao sistema de Pedidos construído no Módulo 2.