viernes, 4 de septiembre de 2009

Microsoft .Net MVC Framework 1.0 … en serio.

video-421 Silencio de radio estos días, ¿lo notaron? Tal vez sí –eso espero-, ya que corté un período de extrema verborragia que abarcó las últimas semanas, aunque –reconozco- con más relleno que ideas.

El relativo silencio tiene su origen en una sucesión de días –y noches-febriles en los que se juntaron el inicio de las clases -con su carga de revisiones, correcciones e improvisado planeamiento (tal cosa existe)- y el inicio de un nuevo proyecto en el trabajo, que es lo que quería comentar en este post, y –por fin- voy al grano.

Este proyecto es mi primera aplicación desarrollada con el ASP.Net MVC de Microsoft y es también el primero que se desarrolla con esta tecnología en la empresa para la que trabajo.

Creo que puede ser interesante ir comentando a medida que avanzo. Muchos de ustedes son programadores y seguramente han trabajado, jugado o leído algo sobre el MVC de Microsoft, y saben muy bien que el partido se juega muy diferente al entrenamiento con ejemplos y tutoriales: la funcionalidad requerida no es negociable (salvo en pequeños detalles), hay que terminar en tiempo y forma, y la presión de no saber (no saber estimar, no saber cómo se hacen tareas comunes, no saber si el framework cubre o no determinada necesidad, no saber si algo es fácil o difícil…) y tener que cumplir, pesa.

El Proyecto.

El proyecto es pequeño, dos programadores con una agenda de aproximadamente cuatro semanas de trabajo. Es una típica aplicación de gestión del estilo pantalla-contra-base-de-datos, con dos o tres complicadas y el resto ABM’s. Pero cargamos también con cierta obligación de entregar como subproducto la experiencia plasmada en herramientas puedan reutilizarse y métodos y prácticas estándar que puedan transmitirse… y errores que no vuelvan a repetirse.

Experiencia.

Somos dos programadores senior, y me toca aportar la experiencia previa de haber trabajado con el patrón MVC los últimos 3 años, si bien implementado sobre un framework desarrollado ad-hoc y mantenido, corregido y mejorado constantemente por el mismo equipo durante ese largo período de tiempo.

Herramientas: primeras decisiones.

Ya dije que trabajamos sobre C#, sobre el .Net 3.5 con el MVC 1.0, resta aclarar que la aplicación trabaja sobre Oracle. Demasiadas innovaciones para un sólo proyecto (en mi caso), así que decidí implementar entidades y acceso a datos con plantillas de CodeSmith, una herramienta de la cual no estoy enamorado pero manejo, y que para mí representa un problema menos.

De lado del cliente utilizamos el framework de javascript jQuery (algo sin lo cual ya no vale la pena vivir), con jQuery UI y el plugin jqGrid (una súper grilla que hace de todo).

Para ser sincero tengo que aclarar que robé la estética (hojas de estilo y demás) de otra aplicación ya desarrollada para el mismo cliente, así que no puedo opinar demasiado en cuanto a las facilidades para el diseño de estas herramientas, salvo que son muy fáciles de reproducir copiando y pegando archivos.

Curva de aprendizaje de MVC.

Estoy comentando aquí la curva de aprendizaje del patrón MVC en sí mismo: cuánto se tarda en aprender los conceptos, los términos, la nomenclatura y darse un par de palos contra la pared hasta llegar a ese punto en el que “vemos en MVC”, es decir cuando logramos encajar intuitivamente las funcionalidades requeridas dentro del patrón.

Así que no vale mi experiencia, sino la de mi compañero de proyecto –programador senior con buena predisposición y mucha experiencia con .Net-, que creo que luego de tres días completos de idas y vueltas (más o menos) ya le está tomando la mano (¡que comente!).

Para recomendar: comenzamos con estos videos cortos de Microsoft, un muy buen punto de partida.

Impresiones del .Net MVC 1.0.

Mi primera impresión fue “esto es buenísimo, es más o menos la misma arquitectura que venía implementando a mano, con los detalles escabrosos ya resueltos y muy bien integrada con el Visual Studio”.

Pero apenas completados los primeros tutoriales (de esos en los que armamos una aplicación -tan funcional como inútil- de punta a punta en 5 minutos) y comenzado el trabajo “en serio”, aparecieron las falencias. Lo que está está razonablemente bien implementado pero hay algunas cositas bastante desagradables, y mi impresión actualizada es que “le faltan cosas”, y que probablemente la próxima versión (2.0) represente una mejora muy significativa.

Puntos fuertes: la sobria estructura de la plantilla inicial nos ayuda a mantenernos organizados, una muy bien implementada relación entre vista y controlador, sencilla y flexible a la vez, la extensibilidad del framework en general (siempre hay dónde meter los dedos para adaptarlo a nuestra forma de trabajo). Por otro lado hay una comunidad grande y muy activa, con muchos y muy buenos recursos.

Por lo menos tengo que reconocer que el resultado final, el html, es mucho… muchísimo más razonable y manejable que el que produce como salida el .Net “sin MVC”: no más viewstate, no más update panel, no más ver una cosa del lado del servidor y otra (compleja, pesada y que encima no funciona) del lado del cliente.

Puntos débiles: el lado javascript, concretamente en lo más fundamental: carece de un método de conexión sencillo que soporte AJAX entre el cliente y el servidor. Las librerías de Microsoft… miré un poco la documentación y bien gracias, el código ni lo abrí. Como siempre, una copia berreta y muy complicada de algo que es muy fácil de implementar con herramientas ya existentes (en breve la adaptación de la serie al MVC). jQuery está ahí, viene con el paquete casi como una sugerencia, pero no vi ningún tipo de integración real (si alguien puede desasnarme éste es el momento).

Otra que no me gustó es cómo quedan –por defecto- las vistas cuando hacemos pantallas “reales” (y no formularios tontos de ejemplo)… esos “helpers” me recuerdan mucho a ASP 3.0 y la verdad que la legibilidad final, si implementamos las cosas tal como dicen los tutoriales… y… es una mezcla horrorosa de javascript, html y tags del lado del servidor. Pero, veremos en breve, eso es salvable.

La curva de aprendizaje del .Net MVC.

Así que, en resumen: si ya conocemos el patrón MVC y también el framework .Net, veremos que ésta implementación es un grandioso punto de partida que nos resuelve lo básico, un poco más, y nos da la base para armar un esquema de desarrollo realmente ágil.

Pero no está regalado, hay que hacerlo. Los detalles tras bambalinas (vistas tipadas, implementación de validaciones del lado javascript, helpers, bindeo) se vuelven un tanto complejos cuando se los quiere forzar por fuera del muy limitado uso estándar para el que están pensados pero, como dije antes, todavía no tuve un problema al que no le haya encontrado solución con un poco de ayuda de google.

Yo voy… pongámosle una semana a tiempo completo, y me considero en forma para esta pequeña primera aplicación con intenciones de sentar una base para algo mejor.

Promesas.

Mucha teoría, mucho discursito en el aire, ya lo sé. Voy a ir armando algunos posts más complejos con ejemplos y algunas soluciones implementadas. No hay mejor manera de validar la razonabilidad de un esquema que mostrarlo y prestar oído a los comentarios.

4 comentarios:

shermann dijo...

Más que .NET MVC Framework debería llamarse "VC", porque de "M" poco.
Probá LLBLGen antes de de decidirte por CodeSmith.

Cerebrado dijo...

Yo también creo que le falta mucho, y ese fue el motivo de mi ultimo post.

Como dice el comentario previo, poco de M. Y yo agrego, si tenes y podes usar JQuery, es una mejor V.

La C? para qué? JQuery accediendo a WebServices para el modelo, javascript puro para las operaciones en la página. Si querés, una C en javascript/JQuery.

AcP dijo...

La verdad es que entre los dos están llegando a la misma conclusión a la que usualmente llega todo el mundo: finalmente, si pensamos que el código detrás de un aspx como una controladora, prácticamente es un MVC.

Ahora, lo anterior es "MVC mental", es decir, una forma de trabajo que uno mismo se propone y se obliga a seguir.

Lo que tiene de bueno el framework .NET MVC en este sentido es que obliga a que todo el equipo sea consistente con esa forma de trabajar.

¿Vale la pena si en un equipo hay 4 porgramadores senior? Y... no, los senior son suficientemente experimentados como para mantener una línea sin estar obligados, e incluso restringirlos es eliminar la posibilidad de que capeen problemas con arreglos rápidos cuando hace falta.

Ahora, si tenemos 2 senior y 3 junior, ponéle, y no tenés el .NET MVC... ¿cómo hacés para que los pequeñines no te hagan TODO en el código de la página?

el perucho dijo...

Suerte hermano...

Recuerda comentarnos como va el proyecto, pero eso si nos dices la verdad... jajaja