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.

¿Y si no necesito o no quiero utilizar un ‘framework’?

Por supuesto, un desarrollador puede crear toda una aplicación sin seguir ningún framework conocido; puede que sea tan pequeña que no lo considere necesario, que no conozca ninguno que se adapte a sus necesidades, o simplemente no desee dedicar tiempo a seleccionar y utilizar uno.

Sin embargo, a medida que la aplicación crece, un programador competente procurará seguir unas determinadas pautas que le faciliten su trabajo de desarrollo y mantenimiento: separación de presentación y lógica, una sintaxis coherente, etc. La evolución natural sera hacia que, de algún modo, se construirá su propio framework.

Y en vez de definir un estándar, ¿por qué no utilizar uno ya definido, y aprovechar el trabajo de otros muchos desarrolladores? Hacer un desarrollo críptico y difícil de interpretar puede ser útil en un concurso de código ofuscado o para presumir de “gurú”, pero es muy poco útil para desarrollar y mantener una aplicación. El coste inicial (la curva de aprendizaje) de utilizar un framework se compense probablemente en cuanto el trabajo de desarrollo crezca mínimamente.

De acuerdo; pero ¿qué ‘framework’ utilizo?

Buscando en la red se encuentra mucha información sobre los frameworks existentes para las diferentes plataformas y lenguajes. Posiblemente uno de sus principales problemas es que haya demasiados: ya se sabe, lo bueno de los estándares es que hay muchos para elegir . Sin embargo, la elección del framework concreto a utilizar vendrá marcada por:

• El tipo de aplicación a desarrollar
• El lenguaje de programación y otras tecnologías concretas: base de datos, sistema operativo, etc.

Como introducción a los frameworks, Ruby on Rails me parece una buena opción para desarrollar una aplicación web y como ejemplo de lo que es un framework. Dentro del mundo Java, Struts parece uno de los más extendidos.

En conclusión

La utilización de un framework en el desarrollo de una aplicación implica un cierto coste inicial de aprendizaje, aunque a largo plazo es probable que facilite tanto el desarrollo como el mantenimiento.

Existen multitud de frameworks orientados a diferentes lenguajes, funcionalidades, etc. Aunque la elección de uno de ellos puede ser una tarea complicada, lo más probable que a largo plazo sólo los mejor definidos (o más utilizados, que no siempre coinciden con los primeros) permanezcan. Y si ninguno de ellos se adapta a las necesidades de desarrollo, siempre es mejor definir uno propio que desarrollar “al por mayor”.

Suscripción RSS a los comentarios de la entrada. | URI para TrackBack.
menéame    añádeme a del.icio.us

 

Artículos relacionados

• Jornadas sobre testeo de software en Valencia
• jordisan.net : nuevo dominio y página personal
• Una idea para un proyecto (1): TALAIOT
• Patrones de software, MVC y los teléfonos móviles

« Algunas ideas que NO son ciertas sobre las nuevas tecnologías

Por lo menos que no nos duela: un análisis de www.contribucions.org »