Posts Tagged ‘frameworks’

ASP.NET MVC

enero 19, 2008

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.

Anuncios

CakePHP y django

julio 6, 2007

Estoy haciendo las primeras pruebas con CakePHP y viene bastante bien. Si bien muchas cosas ya las había visto en django, CakePHP no tiene nada que envidiarle.

Ambos son dos frameworks basados en MVC. Al parecer ambos muy parecidos a Rails, aunque todavía no he tenido el gusto de jugar con este.
MVC significa, muy por arriba, Modelo Vista Controlador. Si bien django se declara MTV, variante Modelo Template View, la idea es muy similar.

Ambos manejan Modelo como un ORM. Respecto al Modelo CakePHP se basa en extender una clase llamada AppModel que nos provee las funcionalidades CRUD. Esto es similar a los Models de django que heredan de models.Model. Lo más cómodo de CakePHP es que interpreta solo las tablas de la base de datos, si seguimos cierta nomenclatura. También me gusta más la manera que se definen las relaciones. Por otra parte, django tenía las factories de campos y generaba las tablas a partir de cómo había armado el “Modelo”. No digo que una cosa sea mejor que la otra, digo que me gusta más trabajar así.

Los controladores ya no tan son parecidos. Los controladores de django las “views” eran funciones que recibían el request y los parámetros. Para que estos views funcionaran había que asociarlos con una regla de rewrite (idénticas a las de Apache), requería definir a mano un dispatcher (siempre que no se usen genéricos). Estos retornaban un review e indicaban el template al que se asociaban. En CakePHP por cada modelo tengo que definir una clase que hereda de una clase AppController. Definiendo un método para esta clase ya tengo hecho el despacho. Estos métodos se llaman actions.

Las vistas son tal vez el punto más divergente. Es que django tiene su propio sistema de Templates (o Maquetación). Este era un poco extraño al principio, pero con un par de pruebas se terminaba manejando. CakePHP tiene un sistema de Templates que es medio un no-sistema de templates: son tags php los cuales utilizan variables y objetos que se le pasan desde el controlador. No es que en django no pase algo similar, sino que esto es casi como programar los templates en php. En esto me recuerda bastante a este artículo donde se charla acerca de la utilidad de los templates. Así que no hay nada raro en el sistema de templates, los tags y los foreach para iterar listas.

Lo que se extraña es el admin de django. Y estoy medio frustrado porque todavía no pude hacer andar los scaffolds (andamios). Al parecer son como los generics views de django.

Otra cosa que me gusta más de django es el concepto de aplicación bien esquematizado por directorios namespaces. Y de ahí vienen las ventajas de django de estar basado en python que es mucho más elegante como lenguaje orientado a objetos que php. CakePHP utiliza un árbol de directorios donde guardo las vistas en un directorio, los modelos en otro y los controladores en otro más. Si bien hay maneras de separar, esta todo apilado.

Pero irónicamente, la fortaleza de CakePHP es estar desarrollado en php. Y encima compatible con php4 y php5. No voy a entrar en la gran discusión acerca de las ventajas y las limitaciones de php y su relación con los objetos.

Acá en Argentina es mucho más sencillo encontrar hostings que soporten php que python. De hecho prácticamente todos soportan php. El despliegue de django en cambio requiere modificar la configuración de Apache y cargar un módulo más, cosa que pone los pelos de punta de los proveedores de hostings.

Y a nivel global, php sigue siendo el lenguaje web más extendido, no sé si por su flexibilidad o su sencillez, pero creo que tiene mucho que ver la gran comunidad que lo respalda y trabaja con él. La documentación es amplia, todo lo que te puede pasar ya le pasó a alguien. En eso CakePHP me parece que tiene mucho campo para crecer.