Cuando una aplicación PHP empieza a crecer, surge la necesidad de unificar la entrada de las peticiones en un solo archivo. Aquí entra el front controller, un patrón clave para servir páginas web de forma ordenada, evitar duplicación de código y centralizar la lógica compartida entre vistas. Es un concepto fundamental para desarrolladores backend que quieren dar el salto a un trabajo más profesional con servidores.

Qué es un front controller en PHP y por qué importa

En PHP cada archivo .php puede comportarse como una página independiente. Si tienes inicio.php, servicios.php y contacto.php, tienes tres puntos de entrada distintos, cada uno con su propia lógica y sin conexión entre sí. ¿El problema? Cuando quieres compartir algo entre los tres, terminas copiando y pegando código.

Un front controller resuelve esto haciendo que un solo archivo sea el punto de entrada de toda la aplicación. Normalmente ese archivo es index.php, y desde ahí decides qué página cargar.

¿Qué es un front controller? Es un patrón en el que un único archivo recibe todas las peticiones de la aplicación y decide internamente qué página o lógica ejecutar. En PHP suele ser index.php.

Cómo se ve el problema sin un front controller

Imagina la estructura clásica de un sitio en PHP plano [01:30]: el usuario entra a dominio.com/servicios.php y eso dispara directamente ese archivo. Si entra a contacto.php, dispara otro completamente distinto.

Esto genera tres dolores concretos:

• Cada archivo es un punto de entrada aislado.
• La lógica común (autenticación, headers, conexión a base de datos) se duplica.
• Mantener el sitio se vuelve costoso conforme crecen las páginas.

La idea del front controller es justo lo contrario: un solo punto de entrada que orqueste todo.

Cómo implementar un front controller básico paso a paso

La estructura mínima que se trabaja en la clase es sencilla. Dentro de una carpeta front-controller creamos:

• Un archivo index.php que actúa como front controller.
• Una carpeta pages con las vistas individuales.
• Tres páginas dentro de pages: home.php, services.php y contact.php [03:30].

Cada página tiene un HTML simple con un H1 que la identifica. Por ejemplo, services.php muestra un encabezado que dice que es la página de servicios, y lo mismo para home y contact.

Cómo decide el index qué página cargar

El truco está en leer un parámetro por la URL y usar un switch para enrutar. La lógica básica dentro de index.php se ve así:

php

<?php $page = $_GET['page'] ?? null; switch ($page) { case 'contact': require 'pages/contact.php'; break; case 'services': require 'pages/services.php'; break; default: require 'pages/home.php'; break; } Con esto, si entras a `index.php?page=services` se carga la vista de servicios. Si entras a `index.php?page=contact`, se carga contacto. Y si no mandas nada, por defecto se carga `home.php` [07:30]. ### Qué hace `$_GET` y el operador de coalescencia nula La expresión `$_GET['page'] ?? null` lee el parámetro `page` de la URL. Si no existe, asigna `null` para evitar errores. Es una forma limpia de manejar entradas opcionales en PHP moderno. > **¿Para qué sirve `index.php` como front controller?** Centraliza todas las peticiones del sitio en un solo archivo, que decide qué página cargar y permite reutilizar lógica común sin duplicar código. ## Por qué no basta con hacer un require dinámico Una tentación natural es simplificar todo el `switch` con una sola línea tipo `require 'pages/' . $page . '.php';`. Funciona cuando mandas un valor válido, pero **se rompe en cuanto el parámetro está vacío o apunta a un archivo inexistente** [09:00]. Y peor: abre la puerta a problemas de seguridad si alguien manipula la URL para incluir archivos arbitrarios. Por eso el `switch` con casos explícitos, aunque más verboso, es más seguro y predecible. Filtra qué páginas pueden cargarse y descarta cualquier valor que no esté en la lista. ## Qué ventajas reales aporta este patrón Una vez que toda la aplicación pasa por `index.php`, puedes colocar ahí la lógica compartida sin repetirte: - Validación de sesión y autenticación. - Conexión única a la base de datos. - Carga de configuraciones y dependencias. - Manejo centralizado de errores y rutas. Es el primer paso conceptual hacia frameworks como Laravel o Symfony, donde el front controller es la base del sistema de enrutamiento. Lo que ves aquí es una versión muy básica, pero la idea de fondo es la misma que usan los frameworks profesionales de PHP. ¿Ya intentaste convertir alguno de tus proyectos PHP a este patrón? Cuéntame en los comentarios cómo organizaste tus rutas.