Frameworks, framewords y más frameworks

De un tiempo a esta parte, como setas en otoño o urbanizaciones en la costa Murciana, aparecen por estos lares del desarrollo los llamados "Web aplicatión frameworks".

Estos engendros, normalmente de distribución gratuita como la cerveza (incluso, en algún caso, libres como la palabra) y empapados de buenrollismo, permiten el desarrollo rápido de aplicaciones. Implementan las partes más comunes en un desarrollo y las estructuras que permiten adaptarlas a nuestras necesidades concretas. Implican cada uno de ellos una way-of-life diferente para quien las usa y le obliga a conocer sus capacidades y su uso, sus librerías y sus archivos de configuración. Pero, seamos formales, según la Wikipedia:

A software framework is a reusable design for a software system (or subsystem). This is expressed as a set of abstract classes and the way their instances collaborate for a specific type of software.[...] A software framework may include support programs, code libraries, a scripting language, or other software to help develop and glue together the different components of a software project. Various parts of the framework may be exposed through an application programming interface (API).

Como todo en este santo sector, los frameworks tienen sus puntos positivos y negativos y precisamente de eso tratará este artículo.

Al empezar un nuevo proyecto es corriente plantearse la duda sobre el uso de un framework que normalmente ha dado resultados espectaculares a algún compañero. Normalmente, como el tiempo apremia, usamos el susodicho framework para el desarrollo y al susodicho compañero como documentación. Pero hay ocasiones, contadas, en que tenemos unas horas antes de empezar a picar código como monos y nos planteamos, ante la objetivamente gigantesca lista de frameworks en el mercado, realizar un estudio sobre cual de ellos se adapta mejor a nuestro proyecto.

La épica tarea empieza por darnos cuenta de un hecho: si todos estos frameworks ayudan ha solucionar los mismos problemas, ¿porqué hay tantos? y su corolario: ante el tiempo que se debe invertir para analizarlos todos, ¿abandono la aventura y uso el que mi compañero conoce? La sensatez nos llevaría responder positivamente, abandonar y empezar a picar código; pero si fuéramos sensatos seriamos guardabosques y no ingenieros informáticos.

Frameworks verticales y horizontales

Así que seguimos con el estudio. Existen dos tipos de frameworks según su alcance:

• Los verticales: que permiten realizar una (y solo una) tarea. Suelen ser muy completos y en consecuencia, sobrepasan muchas veces el ámbito del proyecto. Un claro exponente es Hibernate, para el mapeo de bases de datos relacionales y objetos.
• Los horizontales: que permiten realizar una aplicación completa. Obligan a adaptar nuestra forma de trabajo a ellos. Un claro ejemplo es Spring.

Tareas comunes

Siguiendo con el estudio, encontramos cuales son las tareas comunes que facilitan los frameworks:

• Ajax: la octava maravilla del mundo Web, el midas de los divs, el hipe de 2006, el alfa y el omega de toda aplicación Web2.0.
• Model-View-Controler: un patrón arquitectural para aplicaciones sencillas que ha sido corrompido para adaptarlo a la Web (pues HTTP no posibilita su implementación) pero que se posiciona como la panacea para el desarrollo Web. Cuando se nombra se suele hacer referencia a la estructura de la capa de presentación de una aplicación.
• Internacionalización y Localización: para adaptar nuestra Web a diferentes idiomas.
• Object-Relational Mapping: para olvidarnos de SQL.
• Testing: permitiendo probar de forma unitaria los objetos que forman la aplicación.
• Templates engine: motor de plantillas que permita el desarrollo rápido de la capa de presentación.
• Form validation:la validación de formularios es una tarea dura y muy común.
• Security: La seguridad entendida como la autenticación y la autorizaciónes obligatoria para el 90% de aplicaciones Web.
• Caching: guardar durante un tiempo las páginas generadas, total o parcialmente, permite ahorrar mucho tiempo de computación. Una buena práctica muy recomendable.

Existen varios frameworks para cada una de las tareas anteriores, pero también existen formas de obtener el mismo resultado de forma sencilla usando las especificaciones básicas de Java (J2SE y J2EE) de forma sencilla si sabemos estructurar correctamente nuestro código. Entonces, ¿es necesario aprender a utilizar un framework? ¿La relación entre los beneficios de su uso y el esfuerzo necesario para su aprendizaje justifican este último?

La respuesta... no os la vamos a dar aquí. Existen situaciones en que usar Spring puede ser bueno, existen situaciones en que puede ser un desastre. Existen frameworks mejores y peores y desarrolladores mejores y peores (incluso mucho peores) y de todo ello depende la decisión final.

Puntos positivos y negativos

Los principales puntos positivos de su uso son:

• Facilitan el desarrollo de aspectos muy comunes si el framework objeto ya se conoce.

Y los puntos negativos:

• Tienen una curva de aprendizaje, en términos generales, importante.
• Suelen sobrepasar el alcance de nuestro proyecto, ofreciendo más posibilidades que las utilizadas.
• Nuestro proyecto dependerá de terceros proveedores, que en caso de descontinuar el framework obligarán a sustituirlo (obligando, en ocasiones, a reescribir el código de nuestro proyecto)
• Sobrecargan la aplicación con librerías y dependencias. Ocupando memoria y en consecuencia reduciendo el rendimiento general del servidor que hospeda nuestra Web.

Conclusiones

El uso de un framework está justificado cuando:

• el equipo de desarrollo está formado en él y tiene experiencia en su uso, y
• el proyecto se adapta perfectamente al framework pues este implementa (y solo implementa) funcionalidades necesarias.

En el resto de casos, el uso de las herramientas incluidas en J2SE y J2EE es recomendado, mejora el control, la velocidad y la independencia de terceros de nuestro código.