Front controller y rutas en PHP

Contenido del curso

Introducción

Bases de un Framework

Refactorización

Acciones restantes

Estructura correcta de archivos

Seguridad

Flujo completo del sistema

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:009:43

Front controller y rutas en PHP

Curso de PHP Avanzado

Clase 6 de 33

Clase 6 / 33

Recursos

Centralizar el acceso a tu aplicación PHP mediante un front controller transforma un proyecto desordenado en una arquitectura mantenible, segura y escalable. Aprenderás a unificar el punto de entrada en index.php, definir rutas en un archivo dedicado y proteger tu código moviendo lo público a una carpeta aparte. Ideal para quien construye su primer blog o sistema en PHP sin frameworks.

¿Qué es un front controller y por qué centralizar el acceso?

Un front controller es un patrón donde todas las peticiones del navegador pasan por un único archivo, normalmente index.php. En lugar de que cada clic abra un archivo distinto, tu sistema procesa todo desde el mismo punto de entrada [01:05].

Esto cambia la forma en que navegas. Antes visitabas archivos sueltos como post.php o about.php. Ahora visitas rutas que el sistema interpreta y resuelve internamente.

¿Qué hace exactamente un front controller? Recibe todas las peticiones HTTP, identifica qué ruta se solicitó y delega la respuesta al controlador correspondiente. Es el portero único de tu aplicación.

La ganancia es directa: dejas de duplicar lógica en cada archivo y empiezas a pensar en rutas, no en rutas de archivo.

¿Cómo organizar la carpeta app y los controladores?

La estructura empieza con una carpeta app que aloja la lógica del proyecto, y dentro de ella una subcarpeta controllers [01:48]. Aquí es donde por semántica renombras tu antiguo index.php a home.php, porque ese archivo ya no es un punto de entrada sino un controlador.

La lógica queda así:

El controlador home.php se encarga de la página principal.
Cada controlador tiene su vista correspondiente, también llamada home.
El único punto de entrada del sistema sigue siendo index.php.

Este cambio te obliga a ajustar las rutas relativas dentro de los controladores. Si antes hacías un require desde la raíz, ahora debes salir dos niveles con ../../ para llegar a la carpeta recursos [05:55]. Es navegación de línea de comandos aplicada al código.

¿Cómo definir un sistema de rutas en PHP con un array?

La idea es desarrollar con intención: antes de escribir código, piensa qué quieres lograr. Crea una carpeta rutas y dentro un archivo web.php que retorna un array asociativo donde la clave es la URI y el valor es el controlador [02:30].

Un ejemplo de cómo se ve esa estructura:

php

<?php return [ '/' => 'home.php', '/post' => 'post.php', '/about' => 'about.php', '/enlaces' => 'enlaces.php', ]; Fíjate en un detalle clave: las rutas **no llevan `.php`** porque ya no son archivos, son rutas lógicas. El `.php` solo aparece en el nombre del controlador al que apuntan. ### ¿Cómo procesa index.php las rutas? Dentro de `index.php` el flujo es sencillo. Recuperas el array de rutas con un `require`, capturas la `URI` que se está visitando y verificas si esa URI existe como clave en el array [03:30]. El chequeo se hace con un `if`: - Si la ruta existe, haces `require` del controlador correspondiente. - Si no existe, respondes con un `exit('404')` simple para indicar que no se encontró. > **¿Por qué usar un array para las rutas?** Porque centraliza la configuración. Cuando necesites una nueva página, solo añades una entrada al array sin tocar el front controller. ## ¿Cómo proteger el proyecto con una carpeta public? Aquí aparece un problema sensible. Si alguien escribe manualmente en el navegador algo como `/rutas/web.php`, el servidor sirve ese archivo directamente sin pasar por el front controller [08:20]. Eso rompe la centralización y expone tu código. La solución es crear una carpeta `public` y mover `index.php` dentro de ella. **Desde el navegador no puedes acceder a archivos que estén fuera de `public`**, así que todo lo demás queda protegido [08:50]. Dentro de `public` solo deben vivir: - El archivo `index.php` como front controller. - Archivos CSS. - Imágenes y otros recursos estáticos. Después de mover el archivo, ajusta las rutas de `require` para salir un nivel más y llegar a la carpeta de rutas y a los controladores. Cuando intentas visitar manualmente `/rutas/web.php`, el sistema responde con tu 404 personalizado porque la condición del `if` se activa correctamente. ### ¿Por qué frameworks como Laravel y Symfony usan public? No es casualidad. Tanto **Laravel** como **Symfony** estructuran sus proyectos con una carpeta `public` por la misma razón: separar lo accesible desde el navegador de la lógica interna [09:30]. Herramientas como **Laravel Herd** funcionan sin configuración adicional precisamente porque respetan este patrón. Adoptar esta convención desde un proyecto propio te prepara para trabajar con frameworks reales sin fricción. ## ¿Qué ganas con esta arquitectura? Tu proyecto pasa de ser un conjunto de archivos sueltos a una aplicación con tres mejoras concretas: - **Front controller**: un único punto de acceso que procesa toda petición. - **Rutas centralizadas**: agregas o modificas páginas tocando solo `web.php`. - **Seguridad por estructura**: lo público está en `public`, lo demás queda fuera del alcance del navegador. Un sistema mantenible es uno que entiendes. Y solo entiendes lo que está bien organizado. El reto ahora es tuyo: adapta el blog que estás construyendo a esta arquitectura y cuéntanos en los comentarios qué parte te costó más resolver.

Introducción

Portafolio en PHP puro sin frameworks

Estructura web básica con PHP y Git

Vistas parciales en PHP sin repetir código

Menú moderno en PHP con Tailwind CSS

Menú activo dinámico con PHP y CSS

Front controller y rutas en PHP

Conexión a MySQL con PDO y consultas dinámicas en PHP

Bases de un Framework

Centralización de conexiones a bases de datos en PHP con PDO

Encadenamiento de métodos en PHP con PDO

Validación de formularios PHP con POST

Clase de validación reutilizable para formularios en PHP

Refactorización

Cómo refactorizar una clase Validator en PHP

Archivos sueltos a controladores en PHP

Conexión de rutas con controladores en PHP

Clase de rutas en PHP con GET y POST

Acciones restantes

Rota DELETE para eliminar registros no CRUD

Formulario de edición precargado desde base de datos

Actualizar registros con PUT en Laravel

Estructura correcta de archivos

Configuración de autocarga con Composer en proyectos PHP

Creación y uso de helpers en PHP para código más legible

Helpers PHP para config, DB y redireccionamiento

Seguridad

Primer middleware PHP para proteger rutas

Refactorización de middleware con clases e interfaces en PHP

Vista de inicio de sesión con PHP y control de acceso

Lógica real de login con base de datos

Cifrado de contraseñas y gestión de sesiones en PHP

Flujo completo del sistema

Separa la autenticación del controlador PHP

Redirección automática después de enviar formularios

Clase SessionManager para mensajes flash en PHP

Helper de errores reutilizable en PHP

Integración de funciones con sistema de sesiones en PHP

Sistema de redirecciones con mensajes en PHP

Middleware para proteger rutas de usuarios logueados en PHP

Front controller y rutas en PHP