Poderia ja ter criado um controller em vez de fazer tudo no progam.
Poderia ja ter criado um controller em vez de fazer tudo no progam.
Oii, Renato!
Boa pergunta. Por três motivos didáticos e técnicos:
Ao usar Minimal APIs (app.MapGet
, app.MapPost
etc.), fica claro o encadeamento rota > verbo HTTP > ação > resposta (Results.Ok
, Results.NotFound
). Isso ajuda a compreender o funcionamento básico de uma API REST sem precisar lidar logo com toda a estrutura de Controllers.
2) Redução de complexidade inicial
No começo, criar controllers acrescentaria mais arquivos, atributos e convenções. Com Minimal APIs, é possível implementar rapidamente os endpoints de CRUD, entender como funcionam rotas e status codes, e só depois evoluir a arquitetura.
A organização vai sendo adicionada aos poucos: primeiro com injeção de dependência (builder.Services
e [FromServices]
), depois com métodos de extensão para separar os endpoints em classes diferentes.
3) Evolução incremental
O curso mostra como sair de um Program.cs
simples e, passo a passo, aplicar boas práticas como SRP (Princípio da Responsabilidade Única). Assim, você pode entender a importância da refatoração e da separação de responsabilidades antes de conhecer Controllers. Isso prepara o terreno para migrar ou complementar com Controllers em projetos maiores.
Quando usar Controllers?
Controllers passam a ser vantajosos quando se precisa de:
[ApiController]
com validação automática e ProblemDetails.Minimal APIs também oferecem recursos modernos (endpoint filters, versionamento, validação), mas Controllers fornecem uma experiência mais completa e organizada quando a aplicação cresce.
Então, o curso começa com Minimal APIs para simplificar e destacar os fundamentos, depois aplica injeção de dependência e métodos de extensão para evoluir a organização. Controllers são introduzidos quando se precisa de mais estrutura, validações automáticas e recursos avançados, sendo uma escolha natural em projetos maiores.
Espero ter ajudado.