MVC

 Faz uns anos que estas letrinhas 'MVC' apareceu por aqui, porém, ainda assim partindo do princípio que todos os leitores já conheciam e sabiam o que exatamente existe neste modelo MVC.


Mas que raios é esse tal de MVC mesmo?! É sobre isso que irei falar hoje :)

Bora lá! O MVC é um padrão de arquitetura de software que separa uma aplicação em três camadas com responsabilidades distintas: Model, View e Controller.

O objetivo é desacoplar a lógica de negócio, a interface do usuário e o controle do fluxo da aplicação, tornando o código mais organizado, testável e manutenível.

OK! acabou, obrigado.

Não, calma! Vou detalhar o que exatamente existe em cada camada, vai pegando a pipoca também...

Model, é a camada de dados e regras de negócio. É o coração da aplicação. Esta camada fica no Back-end. 

Tangibilizando um pouco, o que exatamente fica aqui:

  • Conexão com banco de dados (PostgreSQL, MySQL, MongoDB etc.)
  • Queries e operações de leitura/escrita (CRUD)
  • Regras de negócio e validações de domínio
  • Mapeamento objeto-relacional (ORM/ODM) — ex: Hibernate, Sequelize, ActiveRecord, Prisma
  • Entidades e modelos de dados (classes, schemas)
  • Lógica de cálculo, transformação e processamento de dados

Um exemplo prático: A classe User com métodos como findById(), save(), validatePassword();

View, é a camada de apresentação. Tudo que o usuário vê e interage.. Esta camada fica no Front-end.

 E o que fica aqui:

  • Templates HTML, JSX, Blade, Thymeleaf, ERB etc.
  • CSS e estilos visuais
  • Componentes de interface (botões, formulários, listas)
  • Lógica de exibição (mostrar/ocultar elementos, formatar datas, moeda)
  • Iterações e condicionais de renderização

E por questões de segurança também, o que NÃO fica aqui: Regras de negócio, chamadas diretas ao banco, validações complexas.

Exemplo prático: Um arquivo user_profile.html que exibe os dados do usuário recebidos do Controller.

Controller Aqui está o orquestrador, a camada intermediária. Ela Recebe as requisições, aciona o Model e retorna a resposta para a View (ou diretamente ao cliente, no caso de APIs).

E o que fica aqui:

  • Recebimento e parsing de requisições HTTP (GET, POST, PUT, DELETE etc.)
  • Validação de entrada (campos obrigatórios, tipos, formato)
  • Chamada aos métodos do Model
  • Montagem da resposta (JSON, HTML, redirect)
  • Autenticação e autorização básica (verificar se o usuário está logado)
  • Tratamento de erros HTTP (404, 400, 500 etc.)

Exemplo prático: O método UserController.show(id) que chama User.findById(id) e retorna os dados para renderizar a View ou serializar em JSON.


Fechamos o MVC, basicamente como uma Regra de ouro:

Model não conhece View. View não conhece Model. Controller conhece os dois.

Sempre que você se perguntar "onde coloco isso?", responda:


É dado ou lógica de negócio? → Model

É uma tela ou componente visual? → View

É o fluxo entre uma requisição e uma resposta? → Controller

Pois bem meu povo, é isso. Espero ter ajudado vocês, eu sei que parecia um assunto gigante, algo que não daria pra dominar ou entender... Mas dá sim!


Postar um comentário

Postagem Anterior Próxima Postagem