MVC Pattern: O que é e como funciona no Rails

Talvez você já tenha ouvido falar sobre a arquitetura ou padrão MVC. Caso não tenha, pode relaxar, que vamos conversar a fundo sobre isso.

O que é MVC?

MVC é a sigla pra Model–View–Controller. Ele é um padrão de design de software que define uma forma de organizar uma aplicação, separando responsabilidades.

Na prática, isso significa decidir onde cada parte do código deve ficar e qual é o papel de cada uma delas dentro da aplicação.

Mas por que isso importa?

Quando uma aplicação começa pequena, até dá pra misturar tudo. Com o tempo, isso vira um problema: regras de negócio espalhadas, código difícil de entender e mudanças simples que acabam quebrando coisas em lugares inesperados.

O MVC ajuda a evitar esse cenário. Ele deixa mais claro quem faz o quê dentro da aplicação, o que facilita a manutenção e torna o código mais previsível.

Agora que você já entendeu o que é MVC, vamos falar sobre seus componentes

Model

O model (modelo) no padrão MVC é o responsável por lidar com dados e a parte da lógica do negócio. Isso quer dizer que é ele que vai manter e gerenciar os dados da aplicação, além de definir validações e regras de negócio.

No Rails, você vai encontrar os models dentro da pasta app/models, onde cada model vai representar uma tabela no banco de dados e vai conter as validações e as regras da aplicação.

Deixa eu te mostrar um exemplo pra facilitar.

Vamos imaginar um sistema simples de reserva de salas que contém as seguintes regras de negócio:

• Pra reservar uma sala é necessário ter uma data e horário
• Não deve ser possível ter mais de uma reserva no mesmo dia e horário pra mesma sala

Duas regras simples e bem lógicas né?!

No model do Rails poderia ficar assim:

class RoomReservation < ApplicationRecord
  validates :room_name, :date, :time, presence: true
  validates :room_name, uniqueness: { scope: [:date, :time] }
end

Nesse código, estamos validando se a reserva contém o nome da sala, a data e o horário (presence: true).
Também garantimos que não exista mais de uma reserva para a mesma sala no mesmo dia e horário, usando uma validação de unicidade com scope.

View

Já a view, ela é conhecida como a camada de apresentação visual da aplicação, ou seja, aquilo que o usuário ver e interage.

Com isso, sabemos que a view tem como foco toda a parte de layout e qualquer outro aspecto visual, isso significa que toda a parte de mostrar informações e permitir que o usuário preencha dados pra serem inseridos, vão ser responsabilidade da view.

Considerando isso, tenha em mente que nenhuma lógica complexa deve ser colocada nessa camada.

No Rails, as views ficam dentro da pasta app/views.
Elas são organizadas em pastas com o nome do controller e cada arquivo normalmente representa uma action.

Na prática, o controller busca os dados do model e envia pra view que recebe esses dados e exibe na interface pra o usuário.

A mesma coisa acontece quando o usuário preenche um formulário na tela (view), ele é enviado pra o model.

Ficou claro essa parte?! Beleza, então vamos conversar sobre como é no Rails.

Vamos usar o mesmo exemplo de reserva de salas.

Na view, o papel é apenas exibir essas informações para o usuário, sem se preocupar com regras de negócio ou validações.

<h1>Reservas de salas</h1>

<ul>
  <% @room_reservations.each do |reservation| %>
    <li>
      Sala: <%= reservation.room_name %> <br>
      Data: <%= reservation.date %> <br>
      Horário: <%= reservation.time %>
    </li>
  <% end %>
</ul>

Nesse exemplo, a view apenas percorre a lista de reservas e exibe as informações na tela.

Ela não valida dados, não decide se uma reserva é válida ou não e não acessa o banco de dados diretamente. A única responsabilidade aqui é apresentar os dados que recebeu.

Então, em resumo, na view vão estar todas as coisas relacionadas a forma como os dados são exibidos, isso significa que você verá muita iteração de listas, exibição e ocultação de elementos, formatação de dados, etc.

Controller

Finalmente chegamos no controller. Ele é o responsável por receber a requisição do usuário, decidir o que fazer com ela e preparar os dados que a view vai exibir.

No Rails, o controller fica em app/controllers. E normalmente ele faz coisas como:

• buscar dados no model (ex: listar reservas)
• criar/atualizar registros (ex: salvar uma nova reserva)
• escolher qual view vai ser renderizada

O ponto aqui é: o controller não deveria conter regra de negócio. Ele mais coordena o fluxo do que “pensa”.

Vamos ver esse exemplo no Rails:

class RoomReservationsController < ApplicationController
  def index
    @room_reservations = RoomReservation.order(date: :asc, time: :asc)
  end
end

Nesse exemplo, o controller está só preparando o que a view precisa: uma lista de reservas.

Ele busca os dados no model e coloca em @room_reservations, que é exatamente o que a view usa para renderizar a lista. Só isso.

Fluxo Complexo

Agora que já entendemos o papel de cada camada, fica mais fácil visualizar como elas funcionam juntas no dia a dia.

Vamos usar o mesmo exemplo de reserva de salas para acompanhar esse fluxo.

1. O usuário acessa uma rota, por exemplo /room_reservations
2. Essa rota é direcionada para o controller
3. O controller recebe a requisição e decide o que fazer
4. Para buscar os dados, ele chama o model
5. O model consulta o banco e retorna as reservas
6. O controller prepara esses dados
7. A view recebe os dados e exibe o resultado para o usuário

No nosso exemplo, quando o usuário acessa a lista de reservas, o Rails direciona a requisição para a action index do RoomReservationsController.

Essa action busca as reservas no model RoomReservation e armazena o resultado em @room_reservations.

Por fim, a view index.html.erb usa essa variável para renderizar a lista de reservas na tela.

Aqui uma imagem pra facilitar:

Perceba como tudo fica organizado com o MVC, isso vai facilitar muito no dia-a-dia na manutenção dessa aplicação.

Por isso, o MVC acaba sendo bastante usado e o Rails é totalmente baseado nele.

E já adianto que depois de um tempo programando nesse padrão, essas responsabilidades ficam muito mais simples de entender e de aplicar.

Até a próxima!