ASP.NET WebForms vs ASP.NET MVC, la nueva batalla

ASP.NET Web Forms, basado en armar todo por componentes  ASP.NET MVC - basado en construir todo el renderizado tu mismo

Últimamente los debates de C# o VB.Net quedaron atrás, ahora los nuevos debates dentro del mundillo .Net están entre usar ASP.NET Web Forms o ASP.NET MVC. Imaginen la desorientación sobre el tema, que hasta se dedico una sesión del MIX 2009 a tratar sobre este tema: Choosing between ASP.NET Web Forms and MVC. En los inicios de ASP.NET su principal objetivo era ganar terreno a PHP, JSP, y las otras tecnologías existentes, vendiendo que hacer aplicaciones Web era como hacer aplicaciones Windows, aunque haya un trabajo extra por detrás. Con los años de este Framework el uso de la comunidad ha hecho los Web Forms evolucionen, esfuerzos como reducir el tamaño del ViewState, los CSS Adapters, los Starter Kits, las buenas prácticas, entre otras, han ido mejorando el Framework. De hecho no creo que de Microsoft escuchemos no usen Web Forms, ahora usen ASP.NET MVC, por que por parte de ellos y de la comunidad hubo un gran esfuerzo, y mucho cariño, por hacer que los Web Forms, sean un buen Framework de desarrollo Web.

Antes de empezar quisiera usar y resaltar esta línea de un post de ScottGu relacionado con esta discusión, About Technical Debates (and ASP.NET Web Forms and ASP.NET MVC debates in particular):

“Great developers using bad tools/frameworks can make great apps. Bad developers using great tools/frameworks can make bad apps.”

Al citar esta cifra, creo que deben tener un idea de cual es mi punto de vista. Ahora dividamos el problema, vamos a establecer dos grupos de usuarios para dar nuestros comentarios:

  • Grupo de usuarios experimentados de ASP.NET, que tienen varios proyectos en producción y que no han tenido problemas de rendimiento, tiempo de respuesta, etc, cuando han desarrollado proyectos usando WebForms.
  • Grupo de usuarios nuevos de ASP.NET (y en general nuevos en el desarrollo Web), cuyo primero contacto fue hacer proyectos Web usando ASP.NET, y que no han tenido buenos resultados, han tenido problemas de rendimiento, de tiempo de respuesta, de diseño, y todos los que encontramos en los foros.

Usando el mismo patrón que recomendó Jorge Serrano en este artículo, C# o VB, VB o C#,… la envidia me corroe, si eres un usuario experimentando, no necesitas recomendaciones, sólo revisar las características de ASP.NET MVC y ver si alguna de ellas es la estabas buscando: ASP.NET MVC Overview. Cerramos el tema con ellos, y nos dedicamos a los usuarios nuevos en el desarrollo Web y que van a empezar con ASP.NET.

El problema para los nuevos usuarios, y para los que toman como cierto el mensaje: “Desarrolla Aplicaciones Web como si lo hicieras con Windows Forms, sólo arrastras controles y ya tienes tu Aplicación Web”. Y lo toman literalmente, no necesitan aprender la diferencia entre POST Y GET, no hay porque aprender el significado de QueryString, no es necesario saber si es malo guardar un DataSet en el ViewState de la página, sólo la hago para ya no consultar la base de datos y no tener lenta mi aplicación, no se preocupan en aprender HTML, no se preocupan en aprender JavaScript, entre todas las otras que suelen dejarse de aprender.

Entonces si eres un usuario nuevo en ASP.NET (y si no eres nuevo y no sabes que que usa POST o GET), la recomendación básica es aprender los fundamentos del desarrollo Web:

Estos son WebCasts impartidos por el amigo Jonas Stawski. Es más si pueden traten de hacer pequeñas Web simples usando sólo ASP clásico, verán los resultados y la diferencia cuando después aprendan ASP.NET.

Si ya aprendieron los fundamentos, la elección será más fácil. Por otro lado, tampoco es que ASP.NET MVC cambie totalmente la forma de hacer aplicaciones Web Forms, hay muchas funcionalidades que comparten en un común, la diferencia principal esta en como presentar el fron-ed al usuario, no vamos a entrar en detalles muy técnico por que quizás si fuerzas a cualquier de los dos frameworks puedes lograr la funcionalidad del otro, pero vamos mostrar el siguiente gráfico para mostrar algunas diferencias, y como podemos elegir en que escenario usar uno u otro:

Fuente del gráfico, y otro más detallado.

Como recomendación final, podríamos establecer la siguiente línea para aprender correctamente cualquier de las tecnologías y no caer en las malas practicas:

  • Aprender Html
  • Aprender JavaScript
  • Aprender ASP Clásico
  • Aprender ASP.NET MVC
  • Aprender ASP.NET Web Forms

Aprender al final ASP.Net Web Forms, nos ayudará a entender porque algunas opiniones dicen no usar Web Forms, principalmente por el mágico ViewState que hace que los WebForms sean Stateful, por el contrario de toda la Web que es Stateless.

Otros artículos con algunos detalles de este versus, unos más técnicos que otros:

Saludos,

Descargar masivamente las presentaciones del MIX 2010

Hace algunos meses hice una aplicación para descargar las sesiones del PDC 2009. Y los objetivos eran básicamente dos:

  1. Descargar archivos masivamente que tengan un patrón de nombres en común. No sólo que me sirva para el PDC o el MIX, si no para cualquier descarga de archivos basada en un patrón de nombres.
  2. Mostrar algunas ventajas del despliegue ClickOnce. En las anteriores versiones no habilite las actualizaciones automáticas, pero en la última versión ya se encuentra disponible. Es decir que no tendremos que estar viendo si hay una versión nueva de esta aplicación, esta opción de ClickOnce lo hará de manera automática.

ST2 – Download for Dummies: http://sergiot2.com/DfD/default.htm.

El uso es simple, un ejemplo de como descargar los Slides del MIX 2010:

http://sergiot2.com/blogimages/2010/03Mar/24_Mix_2010_Donwloader.JPG

Mejoras para una siguiente versión:

  • Mostrar el progreso de la descarga.
  • Usar Open Folder Dialog, para seleccionar la carpeta de destino.
  • ¿Ustedes tiene alguna?

Saludos,

Que hacer cuando IIS no te deja publicar un Sitio Web ASP.NET

Con el paso del tiempo y familiaridad nos daremos cuenta que la publicación de un Sitio Web (Web Site) o Aplicación Web (Web Application), es lo más sencillo gracias a la herramienta, es decir, Visual Studio 2005+ o Visual Web Developer Express, sólo hacemos clic derecho sobre el proyecto Web o el Sitio Web, y seleccionamos Copy Web Site o Publish Web Site, y podemos escoger si publicamos directamente hacia un servidor, un FTP, o File System para copiarlo por RED o llevarlo en un USB.

Reducimos el problema, divide y vencerás forever, a llevar los archivos generados a nuestro Servidor Web IIS, que es donde suceden los mayores problemas al publicar un Sitio Web.

Problema Central

En cuanto a la publicación en un Servidor Web, se pondrá más interesante si es que no tenemos acceso remoto al servidor, y sólo podemos copiar los archivos por FTP o subiéndolos vía web, la identificación de problemas será un poco más difícil porque no tenemos acceso a la servidor (verificar permisos en el sistema de archivos, revisar Event Viewer, etc). Por ejemplo, un error en la definición de la de conexión, puede hacer que no podamos acceder a la pagina y confundir sobre el verdadero error, entonces debemos deshabilitar los errores personalizados, en algunos extremos intentar depurar remotamente la aplicación Web (es lo peor que se puede hacer, evitar llevar este tema a los foros). Si una aplicación funciona bien en desarrollo, debería funcionar también en producción sin la necesidad de hacer una depuración remota, sólo es un tema de configuración y permisos.

Alternativa

Una buena práctica si es que recién estamos empezando y el llevar nuestra aplicación a producción se convierte en un grave problema , es tener un página con código “Inline” que sea nuestro robot “buscaerrores”. Cada vez que deseamos publicar una aplicación Web, primero enviaremos a nuestro robot a verificar que la configuración del servidor Web sea el correcta, si el robot pasa la prueba, la publicación del sitio web será una tarea sencilla.

Algunas Ventajas

Ya sea el equipo infraestructura o el equipo de desarrollo, el que realice la publicación de una Aplicación Web, debemos tener un robot que nos permita detectar los siguientes problemas:

  1. Detectar configuraciones incorrectas en el Application Pool de un Sitio Web. ¿Qué es un Application Pool? Por ejemplo, si no tenemos al usuario por defecto en un Application Pool (NETWORK SERVICE), debemos darle ciertos permisos y hacerlo que pertenezca a un grupo especial para que pueda ser un usuario del Application Pool.
  2. Verificar que las conexiones a la base de datos funcionen correctamente. Hay muchos sitios web, que no hay ninguna página que no funcione sin hacer conexiones a la base de datos, es decir que si por alguna razón no cambiaron la cadena de conexión al pasar a producción, o el servidor de base de datos no tiene los permisos correctos, ninguna página web de toda la Aplicación va a funcionar. Por ejemplo sitios web que generan sus menús desde la base de datos, este menú estará presente en todas las páginas.
  3. Verificar que los permisos en el sistema de archivos sea el correcto. Si habilitamos la carga de archivos en nuestra aplicación debemos dar los permisos necesarios al usuario del Application Pool (por defecto NETWORK SERVICE) para que pueda escribir sobre la carpeta donde vamos a poner los archivos.
  4. Cualquier otra verificación que ustedes requieran hacer antes de pasar una aplicación Web a Producción. La idea es dejar una página base, pero ustedes pueden personalizarla de acuerdo a sus escenarios.

El robot, debe ser muy simple y no depender de ninguna otra página o recurso para funcionar:

Y el código fuente debe ser Inline para que funcione independiente si es un Sitio Web o una Aplicación Web:

Descargar Robot para Verificar IIS para ASP.NET.

Anécdota sobre el tema

Recuerdo hace algunos años, en el team “epica” estábamos liberando una nueva versión de un producto Web para uno de nuestros clientes, el Project Manager tuvo problemas durante la presentación de esta nueva versión, sólo llamo para decirme: “La Web no funciona, revisa que puede estar pasando”. El equipo de infraestructura del cliente (un empresa multinacional) no pudo detectar el problema y sólo se liberaba de la responsabilidad diciendo que la aplicación Web no Funcionaba. Después de un par de intentos fallidos por solucionar el problema, el equipo de desarrollo tuvo que ir a resolver el problema. No recuerdo exactamente el problema, pero era más o menos así: anteriormente habían instalando una Aplicación Web, que había cambiado la estructura común del IIS, ellos al instalar nuestra aplicación Web no lo habían hecho correctamente y nuestra Web estaba heredando el archivo de configuración de la aplicación instalada anteriormente, y por eso no funcionaba correctamente. Después de un par de cambios en el IIS Manager, nuestra aplicación Web estaba funcionando correctamente.

Saludos,