Desarrollo web rápido: frameworks
Seré sincero: no me gusta el desarrollo web. Muchas de las tecnologías usadas me parecen un dolor de cabeza (¿cómo hemos llegado a la tercera versión de CSS sin poder anidar propiedades, por el amor de Odín?) por lo que honestamente, quiero pasar el menor tiempo posible teniendo que picar código.
En el desarrollo web (y bueno, en muchos otros desarrollos) se sigue el pattern (¿patrón?) de modelo-vista-controlador o MVC (en inglés también) el cual divide nuestro software en tres partes diferenciadas por su función:
- El controlador, que es la aplicación que utilizará el usuario. Por ejemplo, en desarrollo web al archivo índice (index.php si usamos PHP) se le denomina front-controller y en una arquitectura MVC todas las peticiones a cualquier sección deben de hacerse mediante este controlador. La razón es que así tenemos un único punto centralizado donde iniciar todos los procesos comunes (por ejemplo, crear la base de datos). Es bastante común usar reescritura de URL de forma que si tenemos por ejemplo una sección de encuesta, al entrar a /encuesta el servidor llame automáticamente al index.php sin cambiar la URL. Así tenemos direcciones bonitas.
- El modelo, que viene a ser cada una de las distintas aplicaciones de nuestro software. Por ejemplo, en el caso anterior la encuesta sería un modelo, una sección para registrarse sería otro, una sección para mostrar un listado de una base de datos otro, etc.
- La vista, lo que le mandamos al usuario. En un desarrollo web vendrían a ser las templates y todo el HTML y CSS y JavaScript. Todo lo que representa la presentación.
La relación es la siguiente: el usuario entra en una web donde recibe la vista, y mediante ésta se comunica con el controlador. Dependiendo de la petición que le haga al controlador éste tendrá que cargar el modelo correspondiente, el cuál hara sus respectivas tareas y mandará sus resultados a la vista. Por ejemplo, entramos en cualquierweb.com/encuesta, donde el servidor carga el index.php (controlador) avisándole de que la URL es de la encuesta, el controlador llama al modelo de la encuesta donde se cargan los campos del formulario y sus restricciones, y finalmente estos campos y restricciones son pasadas a la vista que nos muestra un formulario con el que podemos actuar.
Esta arquitectura tiene varias ventajas sobre el estilo convencional (crear un controlador independiente de los demás para cada sección que requiramos: index.php, encuesta.php, listado.php, noticias.php, etc):
- Tenemos un sólo punto de entrada del usuario donde controlamos todo lo necesario (las sesiones, la base de datos, las URL, poner la web en mantenimiento…).
- Como generalmente todas las secciones van a tener el mismo diseño, la vista suele dividirse en distintos trozos cada uno en un fichero distinto: el layout principal, la cabecera, el pie de página, etc. De esta forma si queremos modificar algo que afecte a todas las secciones (por ejemplo, añadir el código de rastreo de Google Analytics o modificar el pie de página) sólo tenemos que hacerlo una vez en un archivo, y no en quinientos.
- La modularidad es más fácil: no es difícil desarrollar un framework MVC en el que sea fácil añadir modelos y ampliar el software sin tener modificar lo que ya está hecho.
Ahora tenemos dos caminos: construirnos nosotros mismos nuestro propio framework o podemos utilizar alguno de los múltiples frameworks existentes. El primer camino te puede llevar a tirarte un rato de los pelos, sobre todo cuando pasa el tiempo y reutilizas tu framework para otro proyecto que necesita «otra cosa» y te das cuenta de que para implementar esa cosa tienes que refactorizar un cacho de código importante.
El otro camino nos ofrece, aparte de una arquitectura MVC ya completada, una serie de clases y funciones que nos permiten ir directos a codificar nuestro software sin tener que tocar los intestinos. Por ejemplo, cuando definimos nuestro modelo utilizando un framework éste se encarga automáticamente de crear las tablas en la base de datos y podemos trabajar con ésta sin tener que tocar una sóla línea de SQL. Otras de las funciones que se suelen proveer son la de posibilidad de utilizar plantillas (para que nuestra vista tenga el mínimo código posible), la generación automática de formularios según los atributos del modelo, soporte para traducciones, cachés, sesiones y autentificación… En otras palabras, nosotros diseñamos nuestra web y punto, la base nos la dan ya hecha.
Además, lo bueno de usar un framework para PHP es que enmascaramos gran parte del lenguaje. En otras palabras, evitamos de cierto modo sufrir la inconsistencia, impredecibilidad y general tocamiento de huevos que supone PHP. Habiendo seguido el desarrollo del lenguaje durante más de una década no puedo decir más que parece que no hay nadie al volante.
Así que si nuestro trabajo es PHP tenemos varias opciones: Symfony, la cuál me la han recomendado ya un par de colegas y la que parece ser la más popular, así como CakePHP, Laravel o CodeIgniter.
Otras alternativas son el clásico Ruby on Rails para los programadores de Ruby. Tuvo un hype tremendo cuando salió, allá en el 2000 y poco, pero desde entonces su popularidad ha bajado un poco. No obstante sigue siendo una elección muy sólida.
Y finalmente está Django con el cuál llevo un par de semanas jugueteando por el mero hecho de que está hecho en Python y Python es una pequeña maravilla del ser humano, y como me convenza no va a haber forma de separarme de él.
Borja V. Muñoz
Latest posts by Borja V. Muñoz (see all)
- Los materiales formativos de emprendimiento de YouBrand están listos - 18/12/2019
- Actividad formativa del proyecto Strategies for Digitalising Adult Educationen Lodz, Polonia // Training activity of the Strategies for Digitalising Adult Education Project in Lodz, Poland - 29/05/2019
- Tercer encuentro transnacional del proyecto YouBrand en Atenas, Grecia // Third Transnational Meeting of the YouBrand Project in Athens, Greece - 22/02/2019
