MVC o Web Forms

Desde que empecé a trabajar con MVC dentro de la plataforma de desarrollo de Microsoft, me he preguntado que va a pasar con las Web forms? En la web podemos encontrar muchos lugares donde la polémica se pone caliente, hay defensores y detractores…claro de las Web forms. Porque el MVC fue recibido con los brazos abiertos por la comunidad, sobre todo aquellos que viene de otras plataformas de desarrollo.
Oficialmente Microsoft dice que las Web Forms es una tecnología madura dentro de la plataforma de desarrollo. Esta declaración es natural ya que con un gran número de proyectos desarrollados en esta tecnología, no puede crear una sensación de pánico, tampoco creo que la vayan a retirar del mercado…al menos no en un corto tiempo.
Tímidamente han dejado entre ver que saben y reconocen de la importancia que tiene el haber permitido que esta nueva tecnología entre a su plataforma de desarrollo, al incluir la versión 2 del MVC como parte de la entrega del Visual Studio 2010; y que están en este momento ya en el desarrollo de la versión 3. MVC es el futuro.
En esta entrega no pretendo hacer una introducción técnica o comparación técnica profunda, más bien quiero resaltar que las diferencias entre ambas tecnologías es muy grande.
Puntos a favor:

• El modelo de desarrollo que se sigue en proyectos con MVC es natural para el protocolo HTTP.
• Los programadores tenemos el control de cada una de las etapas del ciclo de solicitud y de respuesta.
• Por su mismo diseño las partes se hacen más simples de organizar y de entender.
• El patrón mismo hace que la Cohesión sea menos estrecha entre las diferentes partes.
• Java Script se integra naturalmente con nuestro código.
• La aplicación de convenios simplifica la configuración.
• No tenemos que lidiar con problemas relacionados con controles o con el ViewState.
• Podemos crear unidades de testeo que simplifican el proceso de pruebas de la aplicación.
• Se diseño pensando en los principios de diseño que comentamos en la entrega anterior y facilitan la utilización de patrones.

Puntos en contra:

• Para un programador que viene de Windows o del mismo ASP, la curva de aprendizaje puede llegar a ser compleja.
• Para quienes están acostumbrados a usar controles, de cliente o de servidor. MVC no cuenta con este tipo de componentes.

La arquitectura de MVC.
Una breve descripción de los componentes seria:
Controller: Es el encargado de gestionar las solicitudes, controlar el flujo de la aplicación y determinar la correcta respuesta.
View: Se encarga de presentar los datos y el resultado de la validación. No debe contener ninguna lógica de negocio.
Model: Es donde se gestiona la comunicación a las bases de datos, los servicios, etc. En si contiene la lógica del negocio.
La responsabilidad de cada una de sus partes está claramente delimitada. Dentro del controler no se debe realizar ningún intento de acceder a la base de datos. O de realizar validación de la captura. Así como las vistas no deben contener lógica de negocios o flujo de control.
A diferencia de ASP donde el codebehind nos crea la falsa ilusión de separación, cuando en realidad el controler y las vistas están fusionadas en una página. En un diseño fuertemente cohesionado.
Esta separación de componentes facilita el desarrollo y su mantenimiento, al mismo tiempo que apoya el principio DRY que comentamos en la entrega anterior. Un ejemplo de esto sería la validación. Los usuarios reciben los avisos en la Vista. Pero podemos implementar la validación a nivel del Model junto a los datos mismos, por medio de las DataAnnotations, de esta forma no importa en qué vista usemos el model, la validación será la misma.
Otro ejemplo interesante es la posibilidad de crear Vistas parciales del código repetido entre una vista de Creación y una de Edición.
Al leer esta entrega pueden ver que soy un declarado admirador de esta nueva tecnología y creo que Microsoft tuvo un gran acierto al permitir que entrara a su plataforma de desarrollo. En este momento creo firmemente que MVC es el futuro del desarrollo web dentro del Visual Studio.