Javatadas

Saturday August 16, 2003

A VUELTAS CON MVC (MODEL-VIEW-CONTROLLER)

Estamos en la prehistoria de la informática.

No es que esté pesimista. Es la pura verdad. En la rama de la construcción no se pasan la vida discutiendo –constructivamente, porque la verdad es que siempre se aprende un montón de escuchar los comentarios de otros- sobre si un puente se hace así, o un camino asá. Los puentes se hacen desde los tiempos de los romanos, y ya hace 2000 años de eso.

¿A que viene la charlita?

Bueno, lo primero de todo es que se macaban las vacaciones, y el lunes hay que ir otra vez por la oficina. Para los privilegiados que disfrutamos con nuestro trabajo no es tan traumático, pero siempre fastidia levantarse un par de horas antes, y tener que quitarte el pijama.

Y hablando en serio. El tema del patrón MVC es recurrente. Ahora mismo existen tropecientas implementaciones del mismo tema, y navegando un poco por la red encuentras mil documentos que hablan sobre buenas practicas y patrones, todos en torno al MVC, o Modelo 2 como lo llaman los de Sun. En ese sentido, y aunque como veremos más adelante existe cierto acuerdo sobre las buenas prácticas de esta arquitectura, el número de implementaciones existentes puede abrumar un poco a la hora de decidir.

Martin Fowler (en mi opinión un tipo encantado de conocerse a sí mismo, pero con un web de obligado paso: www.martinfowler.com) en su libro "Patterns of Enterprise Application Architecture", toca el tema cuando habla de "Presentación Web", y comenta los siguientes patrones relacionados con MVC (que más que un patrón pasa a ser una arquitectura):

• Model – View – Controller
• Page Controller
• Front Controller
• Template View
• Transform View
• Two Step View
• Application Controller

La gente de Sun, en sus antiguos "Core J2EE Patterns" (me parecen que han sacado un nuevo documento, mucho más centrado en los EJB) hablan de los siguientes patrones relacionados con la arquitectura MVC:

• Intercepting Filter
• Front Controller
• View Helper
• Composite View
• Service To Worker
• Dispatcher View

La gente de Microsoft (¡Si! También se preocupan por las prácticas de Ingeniería de Software, y VisualBasic ya tiene herencia!! –eso sí, será plenamente Orientado a Objetos cuando todo el mundo programe orientado a Aspectos) también tiene sus documentos de patrones empresariales (http://msdn.microsoft.com/practices/type/Patterns/), y en referencia a MVC habla de los siguientes patrones:

• Model-View-Controller

• Page Controller

• Front Controller

• Intercepting Filter

• Page Cache

• Observer

Aplicados a C#, ASP.NET y las plataformas de la órbita Microsoft.

En cuanto a implementaciones, en primer lugar está Structs. La de que todo el mundo ha oído hablar, y que se está empezando a pedir en las ofertas de empleo.

Otras implementaciones MVC son Niggle, Webwork, WebLEAF, Turbine, Velocity, Tapestry, etc. tantas como queramos buscar y Google nos devuelva.

Al es un fuerte defensor de Canyamo, y es normal, pues es el padre de la criatura. Me comprometo a sacar tiempo para bajármelo y echarle un vistazo. (ayudaría que los fuentes estuvieran en un jar, pues no cuesta tanto. A mí, por ejemplo, instalar CVS solo para eso me da mucha pereza. Por eso lo haré desde el curro)

Y cómo no, en nuestra empresa nos hemos ido haciendo nuestro FrameWork MVC. Particularmente me ha servido para comprender las particularidades de este tipo de arquitectura. El problema es que esto no debe ocupar más del 10% de nuestro tiempo, puesto que las Aplicaciones de Negocio son muchas, con volumen y complejidad, y no esperan a nadie.

Por un lado no queremos dedicar recursos al FrameWork MVC propio. Por otro lado, ya hay proyectos desarrollados con este FrameWork. De nada sirve migrar a, por ejemplo, Canyamo, si luego nos vemos dedicando recursos a su desarrollo. En este sentido, Structs me inspira más confianza, porque la comunidad que lo respalda es mayor.

En relación con esto, uno de los puntos que me han parecido más "odiosos" de la arquitectura MVC es el de las VISTAS.

Es relativamente sencillo montar un FrameWork MVC con Acciones, Controladores, Formularios, FormulariosInput (input type html) , CondicionesInput , ChequeosInput (chequeos que se aplican a los campos de formulario antes de pasárselos a una Accion) y Mapeos (relacionan una Accion con su vista y el Formulario del que tomará las entradas del usuario).

Con el tema de las Vistas, la cosa se complica más. Supongamos una página compuesta por varios formularios. Al principio el usuario solo ve un formulario. Cuando lo rellena y lo valida, éste le aparece deshabilitado (no editable) y aparece un segundo formulario más abajo. De forma provisional, utilizamos una variable guardada en la sesión (fase=0, 1, 2) e includes, algo así:

En fín, un churro. En adición, en el XML de mapeos que relaciona Acciones con Formularios y Vistas, habrá que incluir una entrada para saber cual es la fase como consecuencia de la ejecución de una Accion (si todo va bien, la fase siguiente, si no, la fase actual).

Supongo que habrá que echarle un vistazo a Tiles, o a JavaServerFaces, que creo que abordan el problema que planteo (facilitar la construcción y REUTILIZACIÓN) de las vistas de un framework MVC. Otra cosa que me da confianza en Structs es que ya tienen una biblioteca de Custom Tags para los campos de formulario html. De esta forma, asociando a las etiquetas un bean, se renderizarán los formularios, y cuando un campo esté mal introducido, aparecerá marcado en rojo, con su asterisquito, para que el usuario lo vuelva a rellenar (sin hacer nada).