ASP.NET MVC vs ASP.NET WebForms
ASP.NET MVC es un framework que combina la efectividad, potencia y claridad de la arquitectura modelo modelo-vista-controlador (MVC), las más actualizadas ideas y técnicas del desarrollo ágil, y las mejores partes de la plataforma ASP.NET existente.
Es una completa alternativa al desarrollo tradicional en ASP.NET webforms, otorgando considerables ventajas al mismo.
Historia del desarrollo web en la plataforma Microsoft
| Tiempo | Tecnología | Fortalezas | Debilidades |
|---|---|---|---|
| Jurásico | CGI | Simple, flexible, la única opción | Corre fuera del servidor web, costoso en recursos, bajo nivel. |
| Era de bronce | Microsoft Internet Database Connector (IDC) | Corre dentro del servidor web | Un sencillo formateador para consultas SQL y para formatear resultados |
| 1996 | Active Server Pages (ASP) | Propósito general | Interpretado en tiempo de ejecución, promueve el "código spaghetti" |
| 2002/2003 | ASP.NET 1.0/1.1 |
Programación orientada a objetos. Potente infraestructura subyacente. |
Consumo alto de ancho de banda. Código HTML horrible. No testeable |
| 2005 | ASP.NET 2.0 | ||
| 2007 | ASP.NET Ajax | ||
| 2008 | ASP.NET 3.5 |
ASP.NET Tradicional
ASP.NET tuvo un gran impacto cuando fue lanzado, no solamente por ser una plataforma multilenguaje, sino en que llenaba el hueco existente entre las aplicaciones Windows Forms, con estado y orientadas a objetos, y las aplicaciones web orientadas a HTML, intrínsecamente sin estado.
Microsoft intentó ocultar tanto el protocolo HTTP (que es intrínsecamente sin estado) como el código HTML generado (que en el momento no era conocido por muchos desarrolladores) modelando una arquitectura de interfaz de usuario que abstraía esos conceptos a un conjunto de controles. Cada control gestionaba su propio estado a través de las diferentes llamadas al servidor, conectaba los diferntes eventos de cliente y servidor, y se encargaba de generar el html correspondiente.
De esta manera, los desarrolladores no tenían que trabajar con una serie de peticiones HTTP independientes y sus consiguientes respuestas. De esta manera nos olvidabamos de la web, y construíamos nuestro interfaz usando un diseñador de "arrastrar y soltar", y nos imaginábamos que todo sucedía en el servidor.
¿Y qué tiene todo esto de malo?
Aunque la intención fue buena al pincipio, la realidad resultó poco más complicada. A lo largo de los años ASP.NET webforms a demostrado tener una serie de debilidades:
- ViewState: El mecanismo para mantener estado a través de peticiones web, normalmente resultaba en bloques gigantes de código que eran innecesariamente transferidos entre cliente y servidor (muchas veces llegaban a ser cientos de Kb), ralentizando la experiencia del visitante cada vez que clicaban un botón de nuestra aplicación web. ASP.NET Ajax adolece del mismo problema, aún suponiendo que este era el problema que Ajax debía de solucionar. :\
- Ciclo de vida de la página: El mecanismo que conectaba eventos de cliente y servidor, parte del ciclo de vida de la página, llegaba a ser extraordinariamente complicado y delicado, llevando normalmente a errores y problemas de mantenibilidad. Manipular la jerarquía de controles de un webforms comunmente llevaba a errores de Viewstate o eventos que misteriosamente fallaban al ejecutarse.
- Limitado control sobre el HTML generado: Los controles de servidor renderizan HTML, pero nunca el HTML que a ti te gustaría. El código HTML que generan es ineficiente, pesado y no cumple los standards ni hace un correcto uso de CSS. El servidor genera una enfarragosa colección de valores de ID cliente, a los que es muy difícil de acceder via Javascript. (ver ejemplo)
- No hay separación de responsabilidades: El modelo de ASP.NET code-behind pretende desacoplar el código HTML del código de servidor, pero en la realidad se acaba mezclando código de presentación (ej: manipulando la jerarquía de controles) con el de lógica de negocio (ej: accediendo a la base de datos) en la misma, enorme, y difícil de mantener clase de code-behind. Sin separación de responsabilidades, el resultado final se frágil e ilegible.
- Imposible de testear: Cuando se lanzó ASP.NET, no se anticipó que el desarrollo orientado a pruebas iba a ser una práctica común en el desarrollo de software a nivel mundial. Es por ello que esta arquitectura es completamente intesteable.
El desarrollo web hoy
Desde que ASP.NET webforms fue lanzado, ha habido muchos progresos en la industrial del desarrollo web:
Web standards y REST
Las páginas web hoy son consumidas por una gran variedad de dispositivos, por lo que se hace necesario una convergencia hacia unos estándares comunes.
De la misma manera, REST ha ido ganando una gran popularidad y se ha reconocida como la referencia de interoperabilidad entre aplicaciones sobre el protocolo HTTP.
Agile y desarrollo dirigido a test
El desarrollo ágil y orientado a test permite introducir capacidad de adaptación al cambio, sin comprometer la base de código existente, ya que cada funcionalidad o comportamiento deseado está garantizada por varias pruebas unitarias que garantizan su funcionamiento.
Desgraciadamente, webforms no nos facilita (más bien todo lo contrario) el trabajo orientado a pruebas.
Beneficios de ASP.NET MVC
Arquitectura MVC
Desarrollada en los años 80, promulga la separación de responsabilidades entre el controlador de peticiones, el modelo o repositorio de datos y reglas de negocio y las vistas. Esta arquitectura facilita la testeabilidad .
Extensible
Practicamente cada pieza que forma el framework ASP.NET MVC puede ser alterado, o modificado por una implementación propia para cubrir nuestras necesidades. Para cada componente del MVC Framework tenemos 3 opciones:
- User la implementación que trae por defecto (normalmente suficiente para la mayoría de las aplicaciones)
- Crear una clase derivada y modificar el comportamiento deseado.
- Reemplazar el componente deseado por una nueva y completa implementación que cubra nuestras necesidades.
Testeable
La arquitectura MVC facilita la creación de pruebas unitarias. Crear aplicaciones usando metodologías ágiles o basadas en TDD es muy sencillo usando ASP.NET MVC. Ahora nuestras aplicaciones son más robustas.
Control preciso sobre el HTML generado. Control. Control. Control.
Usando ASP.NET MVC podemos escribir el código HTML final que deseemos, control que no teníamos con ASP.NET webforms. Eso significa que nuestras aplicaciones van a generar un código más limpio, que siga los estándares, y que se integre fácilmente con nuestro código Javascript.
URL's elegantes, semánticas y user-friendly
Sustituimos esto: (ASP.NET webforms)
/viewproducto.aspx?id=324
por eso (ASP.NET MVC)
/Productos/Coches/Opel/324/Opel+Astra
Potente sistema de rutado (routing)
ASP.NET webforms ya contaba con un sistema de rutado, pero ha sido con ASP.NET MVC cuando lo hemos exprimido para aprovechar todas sus capacidades. Con ASP.NET MVC, una petición HTTP no tiene que estar necesariamente mapeada a un archivo, sino que podemos crear elegantes y "user-friendly" rutas a nuestro antojo. Ejemplo: Antes con webforms /micoche.aspx?id=3 , ahora con ASP.NET MVC: /Coches/3/Opel-Astra
Sigue el diseño "sin estado" nativo de la web
Ausencia de ViewState, PostBack y todo el tedioso ciclo de eventos de un webforms.
Nos evita gestionar el complejo mecanismo de eventos de cliente y servidor durante el ciclo de vida de la página.
Construido sobre lo mejor de la plataforma .NET
No cabe duda que la plataforma .NET ofrece ventajas considerables de productividad, potencia, seguridad y escalabilidad. ASP.NET MVC hace uso de toda esa base de código.
ASP.NET MVC es open source
ASP.NET MVC es "open source". Puedes descargar la última versión del framework, e incluso modificarla y compilarla a tu gusto. Puedes descargarlo aquí: http://aspnet.codeplex.com/
Unas "buenas" razones para no usar ASP.NET MVC son...
- No te sientes muy a gusto con polimorfismo o POO en general.
- No vas a sacar partido a las funciones de extensibilidad de la plataforma
- Dependes fuertemente de controles de terceros para generar tu código de cliente.
- No te gustan las librerías de código abierto (open source)
Referencias
- Pro ASP.NET MVC Framework, de Steven Sanderson
- http://jeffreypalermo.com/blog/you-should-not-use-asp.net-mvc-if/
- http://stackoverflow.com/questions/102558/biggest-advantage-to-using-asp-net-mvc-vs-web-forms
- http://highscalability.com/blog/2009/8/5/stack-overflow-architecture.html
Tweet
Autor
Desarrollador de software, consultor y formador freelance con más de 13 años de experiencia
Actualmente 100% dedicado a node.js
