¿Qué es un ‘framework’?

El término ‘framework’ se utiliza constantemente en el desarrollo de software, pero… ¿sabríamos definir qué es un ‘framework’? He aquí una descripción.

Muchos de los que nos dedicamos al desarrollo de software utilizamos, conocemos o, como mínimo, nos hemos tropezado con el concepto de framework (cuya traducción aproximada sería “marco de trabajo”). En concreto, y por diferentes motivos, he hecho algún pinito utilizando JavaServer Faces así como en Ruby on Rails.

Sin embargo, el concepto de framework no es sencillo de definir, a pesar de que cualquiera con experiencia programando captará su sentido de manera casi intuitiva, y es muy posible que esté utilizando su propio framework (aunque no lo llame así).

¿Cuál es el sentido de un framework?

En casa del herrero…

Sabemos por experiencia lo importante que es la normalización de datos en cualquier aplicación. Los usuarios pueden manejar su información en papel, fichas, en su propia memoria, tenerla duplicada, con incoherencias, omisiones, … ¡Todo un infierno! Pero una aplicación informática necesita que esa información esté estructurada de un modo conocido para poder manejarla: almacenarla, recuperarla, y todos los “-arla” que se requieran. Para eso definimos modelos de datos con una determinada estructura (que habitualmente se convierten en tablas de una base de datos).

Pero ¿qué ocurre con la información que manejamos los propios desarrolladores para crear una aplicación? Léase código fuente, librerías, ficheros de configuración, etc. Muchas veces parece que la única elección importante es la tecnología concreta a utilizar (lenguaje de programación, gestor de bases de datos, etc.) pero, a partir de ahí, cada programador puede crear su propio maremagnum de ficheros y código fuente.

¿Por qué permitir ese “desorden” en un desarrollo, si estamos tan convencidos de las bondades de estructurar y normalizar la información? Eso es ni más ni menos lo que pretende un framework.

Entonces ¿qué es un ‘framework’?

Siendo muy simple, es un esquema (un esqueleto, un patrón) para el desarrollo y/o la implementación de una aplicación. Sí, es una definición muy genérica, pero también puede serlo un framework: sin ir más lejos, el paradigma MVC (Model-View-Controller) dice poco más que “separa en tu aplicación la gestión de los datos, las operaciones, y la presentación”. En el otro extremo, otros frameworks pueden llegar al detalle de definir los nombres de ficheros, su estructura, las convenciones de programación, etc.

Pongamos un ejemplo: una aplicación web que utilice Java como lenguaje de programación puede implementarse de multitud de formas, mediante servlets y JSPs. Hay algunas convenciones que es necesario seguir, como usar un fichero de configuración web.xml, pero el programador sigue sin tener un patrón claro a seguir para la creación de servlets, clases, JSPs, etc.

En una primera estandarización, la utilización de una arquitectura MVC aconseja que separemos la lógica de la aplicación (en los servlets) de la presentación (usando JSPs); en concreto, no sería correcto codificar lógica de aplicación o accesos a base de datos dentro de los JSP.

Un paso más allá: utilizando Faces como framework, la estructura de la aplicación queda todavía más definida: un único servlet (FacesServlet) va a controlar el flujo de la aplicación; además, el uso de un fichero concreto (faces-config.xml) permite crear la navegación de la aplicación, definir los objetos (beans) pasados como parámetros, etc., todo ello sin necesidad de codificarlo en Java o JSP.

Los frameworks no necesariamente están ligados a un lenguaje concreto, aunque sea así en muchas ocasiones. En el cada vez más popular Ruby on Rails, ‘Ruby’ es el lenguaje de programación y ‘Rails’ el framework; por otro lado, JavaServer Faces está orientado a desarrollos en Java. Sin embargo, nada impide definir el mismo framework para lenguajes diferentes: por ejemplo, existe un framework llamado Biscuit cuyo objetivo es prácticamente convertirse en un “PHP on Rails”. Eso sí, cuanto más detallado es el framework, más necesidad tendrá de ceñirse a un lenguaje concreto.

También es posible que el framework defina una estructura para una aplicación completa, o bien sólo se centre en un aspecto de ella. Siguiendo con los ejemplos, Ruby on Rails ofrece un marco para el desarrollo completo de una aplicación web, mientras que JavaServer Faces está más orientado a la interfaz de usuario.

¿Qué ventajas tiene utilizar un ‘framework’?

Las que se derivan de utilizar un estándar; entre otras:

·         El programador no necesita plantearse una estructura global de la aplicación, sino que el framework le proporciona un esqueleto que hay que “rellenar”.

·         Facilita la colaboración. Cualquiera que haya tenido que “pelearse” con el código fuente de otro programador (¡o incluso con el propio, pasado algún tiempo!) sabrá lo difícil que es entenderlo y modificarlo; por tanto, todo lo que sea definir y estandarizar va a ahorrar tiempo y trabajo a los desarrollos colaborativos.

·         Es más fácil encontrar herramientas (utilidades, librerías) adaptadas al framework concreto para facilitar el desarrollo.