Entradas con la etiqueta “arquitectura”

MVC en la web, la gran farsa de los arquitectos de software

En los entornos de desarrollo web es habitual referirse al patrón de diseño Modelo Vista Controlador (MVC) como la “forma correcta” de construir sitios/aplicaciones web. La realidad es que dicho patrón no se puede aplicar a la web tal y como se concibió, aunque su objetivo resulte útil y entronque con un principio general de diseño frecuente en distintos entornos de desarrollo de software: separar claramente las partes de un sistema. Así de sencillo. :)

Modelo-Vista-Controlador

El paradigma MVC, tal como se presentó originalmente, está pensado para aplicaciones estáticas como las que solemos manejar en un entorno de escritorio. Piensa por ejemplo en tu organizador de archivos (en Windows, en Mac o en Linux): te ofrece un buen número de botones, campos de entrada, controles de ventana, filtros, etc., que pueden ser presionados por ti en cualquier momento. Cuando lo haces, estás activando uno de los muchos “controladores”, su consecuente “modelo” para hacer lo que tiene que hacer, y finalmente actualizando una o más “vistas” que reflejarán el nuevo estado del “modelo”. En la implementación original la cosa quedaba descrita del siguiente modo:

The view manages the graphical and/or textual output to the portion of the bitmapped display that is allocated to its application. The controller interprets the mouse and keyboard inputs from the user, commanding the model and/or the view to change as appropriate. Finally, the model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller).

Es decir, el problema original al que se enfrentaba este “paradigma” era la simultaneidad, en un entorno de múltiples puntos de entrada (en forma de “controladores”) y múltiples puntos de salida (en forma de “vistas”). Lo que nos obliga a preguntarnos: ¿la web es un entorno de ese tipo? Evidentemente no. En la web manejas un sólo punto de entrada (request) y un sólo punto de salida (response), por lo que para empezar te encuentras con un patrón para el cual no dispones de un problema real sobre el que aplicarlo. :(

Pero además te encuentras con que las aplicaciones ideales para MVC son básicamente monousuarias y el modelo se mantiene en memoria mientras la aplicación está siendo ejecutada. Segundo elemento que no encontramos en la web: entorno típicamente multiusuario, donde el modelo para el usuario se regenera en cada request.

Si uno profundiza en las características del paradigma original se irá encontrando con más diferencias, que básicamente son fruto de estas dos básicas que he señalado.

Separa, separa, separa

Si el patrón original no puede ser aplicado realmente a los problemas típicos con los que nos enfrentamos en un entorno web, ¿qué es lo que podemos extraer de él? Sin duda alguna, su vocación por mantener separadas las partes de un sistema: es decir, pon tu código de datos en un lado, tu código de aplicación en otro, y tu código de presentación en otro. No suena a nada del otro mundo, dicho así; parece sentido común, y es al mismo tiempo una forma tradicional de desarrollo de software que encaja muy bien con trabajo en equipo y especializado.

Por lo tanto, no tiene sentido apelar a este patrón como una solución-para-todo, e incluso puede resultar contraproducente, puesto que se van a estar forzando las cosas (las palabras, los conceptos, etc.) y por lo tanto perdiendo perspectiva. Eso en el mejor de los casos; en el peor, se llegará a construir un problema ajustado al patrón y no a la inversa. :(

Bases para el desarrollo web

2 de diciembre, 2008 - por | | Análisis

Cualquier persona que ha participado de alguna forma en un proyecto web, conoce la enorme incertidumbre con la que se trabaja, a causa de las numerosas opciones que se barajan. Tomar una decisión sobre cualquier aspecto conlleva la necesidad -o la sensación de tenerla- de informarse y evaluar las distintas alternativas, a menudo sólo apoyándose en una metodología cualitativa difícil de formular conscientemente.

En todo ésto hay una parte, para mí, asumible de forma natural, que tiene que ver básicamente con el esfuerzo constante por innovar. Las tecnologías nacen para tener versiones, mejoras e incluso ser sustituidas por otras, con lo que los cambios -estructurales o por meras modas- son algo inevitable. Algunas personas piensan, además, que es positivo; y, por supuesto, hay otras que opinan justo lo contrario. La incertidumbre a la que me refería se mueve básicamente en esta parte.

Ahora bien, hay todo otro conjunto de cosas que, en mi opinión, son de naturaleza arquitectónica, y que por eso mismo no deberían verse comprometidas por las otras. Desgraciadamente, muchas veces son las partes más descuidadas de los proyectos, y los problemas que traen consigo suelen convertirse en críticos.

La primera cosa que suele descuidarse es el marcado HTML. Este descuido tiene consecuencias a todos los niveles, puesto que la web se apoya, intrínsecamente, en las estructuras de los documentos. Existe todavía una actitud bastante generalizada que concede poca importancia a este aspecto, produciendo una base de conocimiento muy pobre y poco rigurosa. Recientemente, Opera hacía públicos algunos datos recogidos a través de su herramienta MAMA, que cifraban en tan sólo un 4,13% los documentos existentes en la red validados correctamente. En este tipo de datos lo interesante no está tanto en las cifras, cuanto en la actitud que éstas reflejan.

El descuido en el marcado produce una reacción en cadena de descuidos que, en conjunto, afectan sustancialmente al documento.

Por un lado, existe un riesgo mayor de que estructura y presentación no se comporten como partes estancas, con lo que se incrementa la probabilidad de restringir y/o dificultar el acceso al documento (documentos más pesados, documentos no válidos para algunos dispositivos, etc.), así como de ofrecer un contenido menos significativo.

Por otro lado, aumenta la dificultad de incorporar comportamientos relacionados con el navegador, puesto que éstos se benefician de una estructura bien organizada y limpia de estilos. Ésto, a su vez, incrementa la posibilidad de restringir el acceso a causa de problemas con los dispositivos.

Asimismo, al disponer de un contenido menos significativo, disminuirá la capacidad de acceder a éste mediante búsquedas de patrones y/o semánticas. Lo que repercutirá, nuevamente, en restricción de acceso.

Más importante aún que todo ésto es que este tipo de actitud va en aumento según se desarrolla un proyecto, de forma que las pocas consideraciones que se tenían en el momento 0, han disminuido en el momento 5, y empiezan a considerarse como un problema en el momento 10. A partir de ahí se habrá invertido lo que debería ser el orden natural del proyecto, de forma que la web habrá pasado a considerarse un corsé demasiado pobre que necesariamente hay que forzar.

En ese punto penetrarán todos esos aspectos de la primera parte (tecnologías cambiantes, modas, etc.) desbordando sus límites naturales. En la historia de la web -que escribimos cada día- hay ejemplos de todo ésto -que todos vivimos diariamente- y se puede decir que prácticamente nadie está a salvo, y que es un ejercicio diario hacer el esfuerzo por mantener cada cosa en su sitio.

Merece la pena, puesto que ayuda a gestionar la incertidumbre que se mencionaba al principio, poniéndole límites, y evita la generación gratuita y progresiva de problemas y restricciones a todos los niveles.