ASP.NET MVC

Anoche fui a una TechNight de Microsoft donde presentaron ASP.NET MVC. Los chicos que dieron la exposición estuvieron muy bien, y que haya habido cerveza y papas fritas a la salida me pareció un gran gesto. Eso y los ojos de una muchacha que andaba dando vueltas por ahí, azules como el cielo de este hermoso día.

Mi pregunta era como habían hecho las cosas… No las hicieron mal, solo que las hicieron igual… ¡Ejemplo del blog con comentarios incluido!

Igual a Ruby on Rails, a Monorail, a CakePHP, a todos los frameworks MVC, pero con las tecnologías de VS 2008. Como ORM utilizan LINQ, como API para Sindicación usan WCF, etc.

Algo muy positivo es que los módulos que componen el modelo se comportan como módulos realmente y son intercambiables.

Tiene un router de urls, expresiones regulares para validar. ¡Está todo!

Tal vez lo más interesante sea en que cada parte sea implementada como una interfaz, permitiendo implementar las propias, hacer mock-objects, utilizar sistemas de templates como los de MonoRail o implementar el propio sistema de Ruby On Rails. Es muy flexible en eso. Esto para integrar aplicaciones ya desarrolladas es un golazo.

Otra ventaja -que al programador asp.net medio no le parece tal- es que se van el viewstate y el postback. ASP.NET depende mucho de estas cuestiones y ahí es donde se complican la mayoría de las páginas. Haber transportado el esquema de eventos de Visual Basic a la web es algo que ayuda mucho a acortar la curva de aprendizaje para pasar de una tecnología a otra, pero los dolores de cabeza empiezan cuando hay que hacer cosas en AJAX, o necesitamos manosear el DOM desde javascript. Se puede calcular o directamente obtener el id del DOM de los controles. El drama es cuando estos son generados como ItemTemplates, hay que hacer alguna chanchada. El esquema es bueno en una aplicación de escritorio, pero en web es muy pesado. Esto lleva a que todos los controles que dependían del viewstate y del post-back hayan quedado, bueno, «deprecated». Tendrían que haber visto como se puso la monada cuando los chicos tuvieron que avisar que el GridView no iba más. AJAX.NET también se ve comprometida.

Tranquilos muchachos, están los Helpers de la UI para generar nuestros nuevos controles. En vez de Viewstate usamos el cache del lado servidor. Es programar un poco más, pero podemos armar nuestro propio Viewstate usando la Cache. Y ganamos obteniendo páginas y sesiones más livianas.

Con .NET 3.5 hay variables tipadas dinámicamente, saludando al variant de VB. Sinceramente, si no era porque las variables NO empezaban con $, hubiera jurado que estaba viendo código PHP y templates de CakePHP en Visual Studio 2008.

Otra cosa es que IIS 7 ya permite Rewrite Rules o algo por el estilo. Lo que nos permite hacer la magia de las urls amigables a la intuición del usuario y a los buscadores.

La verdad es que me parece muy bueno que ASP.NET provea la posibilidad de trabajar con MVC, al margen de que yo lo haga. Le da al desarrollador un enfoque nuevo muy útil en varios escenarios.

Espero que le den para adelante, porque se va a ganar mucho en flexibilidad y legilibidad del código. Pero tal vez lo mejor es que trabajar con MVC nos ayuda a identificar mejor los requerimientos de nuestra aplicación y trabajar en función de ellos. Después si tiene que salir en ATOM, XHTML o código morse ya es problema de la vista y sus helpers. Nosotros tenemos nuestro controlador que hace el trabajo importante.

Yo voy a seguir firme junto a PHP5, SPIP y CakePHP en trabajo independiente, dado que no tengo un IIS7, ni plata para comprar un módulo ISAPI de redirección para IIS6 (otra cosita que tuvieron que contar los chicos), pero ASP.NET MVC sería mi «weapon of choice» a la hora de trabajar en web con .NET.

Etiquetas: .net, CakePHP, desarrollo web, frameworks