¿ASP.NET MVC ó WebForms?

Siguiendo con la línea editorial del artículo pasado me propongo en esta ocasión analizar las diferencias entre las dos opciones estelares de la plataforma .net para el desarrollo web: asp.net mvc y WebForms.

WebForms

Podríamos decir con respecto a WebForms que se trata de la simulación para la web de la visión de Rapid Application Development sostenida por Microsoft, puntualmente, de su visión del desarrollo de aplicaciones para sus sistemas operativos. Por tanto MS intentó minimizar el impacto y la curva de aprendizaje de los desarrolladores acostumbrados a trabajar en ambientes de escritorio mediante WebForms. Digamos que con WebForms se lograron cosas interesantes desde mi punto de vista y que supusieron una victoria (aunque ahora desde la luz del TDD y MVC parezcan derrotas), una de ellas, por ejemplo, el concepto de CodeBehind que permitía separar las etiquetas asp de la clase que las manejarían. Entonces ocurre con WebForms que manejo el desarrollo de mis páginas web orientado a eventos y se introducen dos conceptos importantes: el ViewState y el Postback, necesarios para que dicho modelo funcione. Todo eso que parecería una ventaja, para algunas situaciones empezó a convertirse en un problema y a medida que nuestros desarrollos crecían también el volumen de datos que debido al ViewState debía viajar en cada solicitud o respuesta hacia y desde el servidor se hacía considerable impactando el performance de la aplicación. Adicionalmente, en la medida en que iban ganando mercado otros navegadores la compatibilidad con los mismos se veía comprometida puesto que, reconozcámoslo, la emisión de html de los controles de servidor de WebForms no respeta cabalmente los estándares. Otro aspecto que debía considerarse es el hecho de que las urls creadas por este modelo de desarrollo estaban orientadas a archivos con extensiones por lo tanto la optimización para motores de búsqueda era precaria. Y un largo etcétera, como que se hacía prácticamente imposible el testeo de unidades de UI o que los desarrolladores se abstraían tanto de la implementación del HTTP que se acostumbraban a que la web tuviera estado, cuando lo natural es que no. En fin…

ASP.NET MVC

Y llega ASP.NET MVC. No voy a ahondar en el hecho de que es una implementación del Modelo-Vista-Controlador y lo que ello significa, no. Haré más bien un resumen de los puntos fuertes frente al modelo de desarrollo de WebForms. Empecemos por decir que se vuelve al concepto de la web sin estado por tanto las idas y vueltas al servidor son mucho más descongestionadas. Adicionalmente se reemplazan los eventos por acciones de controlador asociadas a los tradicionales verbos del HTTP (GET, POST, PUT, DELETE) y se logra una separación de conceptos que facilita el TDD. En la capa de la vista se usan plantillas Html lo que asegura en gran medida que se respetarán los estándares y se atenderán de manera óptima diversos navegadores, así como que se tenga mayor compatibilidad con Ajax como concepto. Otro aspecto importante es que las urls vuelven a estar basadas en recursos permitiendo optimizaciones para motores de búsqueda. Y otro largo etcétera que no es más que el hecho de volver a las bases del desarrollo web con un potente framework de fondo para la atención de tareas de propósito general. Como desventajas están el hecho de que los controles de UI vuelven a hacerse medianamente básicos y que el desarrollo se dilata un poco puesto que ya no se trata de arrastrar y soltar ni del tradicional desarrollo-orientado-a-clics de las herramientas MS. En ese sentido debemos ser justos y reconocer que los HtmlHelpers minimizarán ese impacto – tanto más cuando hay unos bastante interesantes en la primera versión del framework mvc – y que Visual Studio sigue siendo una herramienta sumamente potente en términos de minimizar los esfuerzos de desarrollo (aquí me permito hacer un reclamo y es el hecho de que la edición express de VWD actual no lo es tanto para asp.net mvc; espero que la edición 2010 sí lo sea).

Conclusiones

Lo anterior no significa que WebForms esté condenado a desaparecer, no. Ni mucho menos. MS ha sido claro en que seguirá brindando soporte, investigación y desarrollo a ambas opciones de manera paralela. A lo que se debe enfrentar el desarrollador actualmente es a la decisión de cuál usar en sus nuevos proyectos (o incluso si incorpora mvc a los anteriores puesto que pueden coexistir en el mismo proyecto). Yo basaría esa decisión en lo siguiente:

• Si se trata de una aplicación corporativa (intranet o web) en la que la orientación a datos es fuerte (todas esas grillas de datos y sus facilidades) y los tiempos de respuesta no son el primer factor a tener en cuenta (hablábamos con Yeison García hace poco que en este tipo de aplicaciones los tiempos de respuesta no son un factor fundamental) yo recomiendo usar WebForms por varias cosas: el conjunto de controles UI y de componentes (bendito seas ObjectDataSource) es mucho más amplio, los tiempos de desarrollo se minimizan y los resultados pueden considerarse más estructurados.
• Si se trata de una aplicación web en todo su esplendor de propósito general y orientada a atender usuarios de diverso calibre – lo que es la web 2.0 –, abiertas al público recomiendo ASP.NET MVC. También si se trata de proyectos basados en metodologías como agile en los que la orientación del desarrollo es al testeo recomiendo ASP.NET MVC.

Prácticamente el principal factor a tener en cuenta es si la aplicación está orientada a atender el público en general o es de carácter privado. Ya lo demás son concepciones del desarrollo web.