1. O problema que MVC resolve
Sem uma arquitetura definida, é comum um código de tela acabar fazendo tudo ao mesmo tempo: ler dados do banco, aplicar regra de negócio, formatar HTML e responder à requisição — tudo misturado no mesmo arquivo. Isso funciona para uma tela pequena, mas trava o desenvolvimento assim que o sistema cresce: mudar como um dado é exibido arrisca quebrar como ele é calculado. MVC (Model-View-Controller) separa essas três preocupações em peças distintas.
Fig. 1 — O fluxo de uma requisição MVC: Controller orquestra, Model calcula, View exibe.
2. As três peças, uma a uma
| Peça | Responsabilidade | Nunca deveria |
|---|---|---|
| Model | Representar dados e regras de negócio (as classes do Módulo 1, os repositórios do capítulo 12) | Saber como algo é exibido em tela |
| View | Gerar a saída (HTML) a partir de dados já prontos | Conter lógica de negócio ou acessar o banco diretamente |
| Controller | Receber a requisição, chamar o Model, escolher a View e devolver a resposta | Conter regra de negócio complexa ou lógica de apresentação |
Se você já organizou uma API Express/Node em routes,
controllers e models (um padrão comum
mesmo sem um framework MVC formal), o conceito já é familiar — ASP.NET Core MVC só formaliza
essa separação como parte do próprio framework, com convenções e ferramentas de suporte.
3. Onde as procedures do Módulo 2 entram nisso
As procedures que você escreveu no Módulo 2 vivem dentro da camada de Model — tipicamente acessadas através de um Repository (padrão visto no capítulo 12 do Módulo 1), chamado por um Service, que por sua vez é chamado pelo Controller:
Fig. 2 — A procedure do Módulo 2 fica no fim da cadeia — o Controller nunca a chama diretamente.
4. Um vislumbre do Controller (aprofundado no próximo capítulo)
public class ClienteController : Controller
{
private readonly ClienteService _service;
public ClienteController(ClienteService service) => _service = service;
public async Task<IActionResult> Detalhes(int id)
{
var cliente = await _service.ObterOuFalharAsync(id); // chama o Model
return View(cliente); // escolhe a View, passa os dados
}
}
Note que o Controller não sabe como ObterOuFalharAsync
busca o cliente (se é via EF Core, Dapper, ou uma procedure) — essa é exatamente a separação de
responsabilidades que MVC formaliza.
5. Onde isso te leva
Com o panorama geral estabelecido, os próximos capítulos aprofundam cada peça: Controllers e Routing, Views com Razor, e a diferença entre Models, ViewModels e DTOs — uma distinção sutil mas importante que aparece o tempo todo em código ASP.NET Core real.