¿Cómo funciona la arquitectura MVC en Rails?

La arquitectura MVC divide tu aplicación en tres partes: el Modelo, la Vista y el Controlador, y Rails la usa para mantener tu código ordenado y fácil de mantener.

¿Alguna vez abriste un proyecto de código y no entendiste nada? Eso pasa cuando no hay estructura. MVC resuelve ese problema.

¿Qué significa MVC?

MVC son las siglas de Modelo, Vista y Controlador. Cada parte tiene una responsabilidad clara y separada.

Piénsalo así: en una tienda Liverpool, hay tres roles distintos. El almacén guarda los productos (Modelo). El aparador muestra lo que hay (Vista). El vendedor conecta al cliente con el almacén (Controlador).

En Rails, esos tres roles viven en carpetas separadas dentro de tu proyecto. Cuando algo falla, sabes exactamente dónde buscar.

El viaje de una petición en Rails

Antes de ver cada pieza, imagina este recorrido completo.

Tú abres tu navegador y escribes http://localhost:3000/productos. El navegador manda una petición a tu aplicación. Rails la recibe y empieza un proceso muy ordenado.

Primero pasa por el enrutador (routes.rb). Luego llega al Controlador. El Controlador le pregunta al Modelo. El Modelo consulta la base de datos. El resultado regresa al Controlador. El Controlador se lo pasa a la Vista. La Vista genera el HTML. Tú ves la página en el navegador.

Ese ciclo completo ocurre en milisegundos. Y cada paso tiene su lugar.

El Modelo: donde viven tus datos

Carlos trabaja como desarrollador freelance en Monterrey. Su cliente le pidió una tienda en línea para vender uniformes escolares.

Cuando Carlos creó el modelo Producto, Rails generó automáticamente un archivo en app/models/producto.rb. Ese archivo conecta su código con la tabla productos de la base de datos.

El Modelo hace tres cosas principales. Primero, representa una tabla de la base de datos. Segundo, valida que los datos sean correctos. Tercero, define las relaciones entre tablas.

Así se ve un modelo básico en Rails:

class Producto < ApplicationRecord
  validates :nombre, presence: true
  validates :precio, numericality: { greater_than: 0 }
end

Ese modelo le dice a Rails: "Un producto siempre debe tener nombre, y su precio debe ser mayor a cero." Si alguien intenta guardar un producto sin nombre, Rails lo rechaza automáticamente.

Carlos también definió una relación: cada producto pertenece a una categoría. Solo escribió belongs_to :categoria y Rails hizo el resto. Sin SQL manual, sin configuración extra.

El Modelo no sabe nada de pantallas ni botones. Solo sabe de datos. Esa separación es clave.

El Controlador: el cerebro de tu aplicación

Sofía es desarrolladora junior en una agencia digital de Ciudad de México. Su equipo construye una plataforma de recursos humanos para empresas medianas.

Un día, su jefa le pidió crear la funcionalidad para listar empleados. Sofía abrió el archivo app/controllers/empleados_controller.rb y escribió esto:

class EmpleadosController < ApplicationController
  def index
    @empleados = Empleado.all
  end
end

Ese método index hace algo simple: le pregunta al Modelo todos los empleados y los guarda en la variable @empleados. El @ al inicio significa que esa variable estará disponible en la Vista.

El Controlador no genera HTML. No valida datos de negocio. Solo coordina: recibe la petición, habla con el Modelo, y le pasa la información a la Vista.

Sofía cometió un error común al principio: puso lógica de negocio en el Controlador. Escribió cálculos de nómina directamente ahí. Su jefa le explicó la regla de oro: "Lo que tenga que ver con datos, va en el Modelo. El Controlador solo orquesta."

Esa corrección le tomó una hora, pero aprendió algo que usará toda su carrera.

La Vista: lo que el usuario ve

Las Vistas viven en la carpeta app/views. Rails usa un formato llamado ERB (Embedded Ruby), que mezcla HTML con código Ruby.

Siguiendo el ejemplo de Sofía, ella creó el archivo app/views/empleados/index.html.erb:

<h1>Lista de empleados</h1>

<% @empleados.each do |empleado| %>
  <p><%= empleado.nombre %> — <%= empleado.puesto %></p>
<% end %>

Fíjate en la diferencia entre <% y <%=. El primero ejecuta código Ruby pero no muestra nada. El segundo ejecuta y muestra el resultado en pantalla.

La Vista no hace cálculos complicados. No consulta la base de datos. Solo muestra lo que el Controlador le mandó. Si la Vista empieza a tener mucha lógica, es una señal de que algo está mal en tu arquitectura.

Cómo se conectan las tres partes

Hernán dirige un pequeño negocio de software en Guadalajara. Su equipo desarrolla un sistema de inventario para una cadena de farmacias.

Un día necesitaron agregar una pantalla que mostrara productos con precio menor a $500. Así resolvieron cada capa:

En el Modelo (producto.rb), agregaron un método llamado baratos:

def self.baratos
  where('precio < ?', 500)
end

En el Controlador (productos_controller.rb), llamaron ese método:

def ofertas
  @productos = Producto.baratos
end

En la Vista (ofertas.html.erb), mostraron los resultados:

<h1>Productos en oferta</h1>
<% @productos.each do |p| %>
  <p><%= p.nombre %> — $<%= p.precio %></p>
<% end %>

Cada capa hizo lo suyo. El Modelo sabía cómo filtrar. El Controlador conectó todo. La Vista mostró el resultado. Eso es MVC funcionando perfectamente.

Hernán dice que este patrón le permite agregar desarrolladores al equipo sin caos. Cada quien sabe dónde trabajar sin pisar el código de otro.

Errores comunes al empezar con MVC

El error más frecuente es poner lógica en el lugar equivocado. Veamos tres casos típicos.

Error 1: Consultas de base de datos en la Vista. Algunos principiantes escriben Producto.all dentro del archivo .html.erb. Eso funciona, pero rompe la separación de responsabilidades. Si cambias la base de datos, tienes que buscar en tus archivos de vista. Es un desastre.

Error 2: HTML en el Controlador. Generar etiquetas HTML dentro del controlador es igual de problemático. El Controlador no debería saber nada de cómo se ve la pantalla.

Error 3: Lógica de negocio en el Controlador. Si calculas descuentos, impuestos o comisiones directamente en el Controlador, ese código no se puede reutilizar fácilmente. Muévelo al Modelo o a un objeto de servicio.

Recuerda: el Modelo sabe de datos, el Controlador coordina, la Vista muestra. Así de simple.

¿Por qué MVC hace tu trabajo más fácil?

Cuando Rails sigue MVC correctamente, agregar funciones nuevas es predecible. Sabes exactamente dónde poner cada cosa.

Si trabajas en equipo, un desarrollador puede modificar la Vista sin tocar el Modelo. Otro puede ajustar la lógica del Controlador sin afectar el HTML. Esa independencia reduce conflictos y errores.

Además, las pruebas automatizadas se vuelven más simples. Puedes probar el Modelo sin necesitar un navegador. Puedes probar el Controlador sin una base de datos real.

Empresas como Mercado Libre construyen sistemas enormes sobre estos principios. La escala cambia, pero la lógica es la misma que usarás tú desde hoy.

Lo que llevas de esta lección

Ya entiendes cómo viaja una petición desde el navegador hasta la respuesta final. Cada parada tiene su función. Respetarla hace tu código más limpio, más fácil de leer y más fácil de mantener.