VitaminasDEV

¿Necesitas información? ¿Quieres un curso a medida?: hola@vitaminasdev.com

Versión para imprimir

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.

ASP.NET webforms intenta reproducir el modelo de desarrollo orientado a eventos usando en escritorio

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

ASP.NET MVC es 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.

ASP.NET MVC genera código HTML limpio

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 MVC implementa un potente sistema de 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

ASP.NET MVC está construido sobre lo mejor de la plataforma ASP.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




Autor

Iván Loire
Iván Loire

Desarrollador de software, consultor y formador freelance con más de 13 años de experiencia

Actualmente 100% dedicado a node.js

Web: http://www.iloire.com

Consulta su perfil: Iván Loire en LinkedIn

Otros recursos abiertos destacados

blog comments powered by Disqus