Evento Microsoft - Aplicar DI en MVC (23-03-2012)

Para los que no lo sepan, DI son las siglas en inglés de Dependency Injection (Inyección de Dependencias). El próximo 23 de Abril, tendrá lugar un interesante evento (online y gratuito), donde se explicará en detalle en qué consiste DI, y cómo usarlo en proyectos MVC.

El link de registro y más información:
https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032508692&Culture=es-ES

ASP.NET MVC (III)

Este artículo forma parte de una serie. Podéis ir directamente a las partes 1 y 2.

Hoy vamos a ver MVC desde otro punto de vista. Primero, una comparación con los Web Forms tradicionales. En la figura siguiente, se ilustra bastante mejor esta significativa diferencia:

En primer lugar hacer notar que ya no tenemos los eventos, el ciclo de vida de los web forms a los que estábamos ya tan acostumbrados. Ya se rompe por fin el patrón de trabajo (artificial por otro lado), que habían impuesto estos web forms:

1. Procesar una petición
2. Entrar en el ciclo de vida del documento
3. Tratar el evento
4. Pintar los controles
5. Devolver el resultado

Además, el patrón de trabajo de Web Forms nos había acostumbrado a otras cosas totalmente ajenas a la realidad de la web, basándose en esa capa virtual:

1. RAD
2. Controles ricos
3. Modelo dirigido por eventos (lo comentado justo hace un momento)
4. Desarrollo parecido a Windows Forms. Sin querer, estamos creando la ilusión de que trabajamos con una especie de formularios Windows. Nada más falso, tal y como hemos visto en el ciclo de vida de los Web Forms, justo hace un momento.
5. Difícil implementación de TDD. No es nada imposible, pero la verdad es que con los Web Forms había que hacer auténticas piruetas para establecer un TDD en condiciones.
6. Páginas pesadas (por culpa del viejo conocido ViewState).

Aquí hacer un inciso. Anque MVC está muy orientado al uso extensivo de HTML5, CSS3 y Javascript, debemos ser conscientes de una serie de realidades:

1. HTML5 no está disponible para todos los navegadores, hay que validar las funcionalidades antes de usarlas.
2. CSS3 evoluciona mucho más lento que HTML5. TODAVIA NO ES UN ESTANDAR, sino un borrador. Hay que validar el soporte de sus funcionalidades en lugar de validar la versión del navegador o el tipo. No se trata de que Chrome o Firefox o X soporten CSS3...es que CSS3 aún no existe como tal, y está sujeto a cambios.
3. JavaScript: NO ES UN ESTANDAR! El estándar actual, es ECMA-262 (versión 5, Dic. 2009). Y a él nos tenemos que aplicar. Todo lo demás, será favorecer que nuestras páginas funcionen en un navegador y en otros no.

Estructura de una aplicación MVC

Volviendo a MVC, vamos a ver su estructura. Con MVC, trabajaremos con proyectos, no con sitios web ("web sites"). Es lo primero que observaremos, ya que al crear un sitio web con Visual Studio, lo haremos a través del cuadro de diálogo "Add New Project".

La mayoría de los contenidos son ya conocidos en un proyecto ASP.NET (como App_Data, Web.Config, scripts, etc.) Sin embargo, hay carpetas específicas de un proyecto MVC:

• Content: en esta carpeta tendremos los archivos estáticos, como imágenes, hojas de estilos, y archivos html puros.
• Controllers: en esta carpeta, encontraremos todas las clases controlador. En general, por cada entidad en nuestro modelo, tendremos un único controlador. Además, podemos definir otros controladores para otras acciones como: LoginController, HomeController, NavigationController...Como podéis ver, para las clases controlador, se suele utilizar la convención NombreEntidadController.
• Models: Aquí se encuentra el código que representa el modelo de negocio. Este código interactúa con la base de datos y procesa las reglas de negocio. Si usamos Entity Framework, tendremos los archivos EDMX aquí. Por supuesto, podremos tener una dll separada, referenciada por el proyecto que contenga el modelo, por lo que en ese caso esta carpeta estaría vacía.
• Views: Aquí encontraremos las vistas (páginas ASPX, ASCX y master pages). Normalmente, la convención indica que hagamos una carpeta separada para cada controlador. Aquí también hay una carpeta llamada Shared, que se usa para vistas comunes a varios controladores (como una master page).



ASP.NET MVC (II) Ventajas

Vamos a continuar con esta serie de posts sobre ASP.NET MVC. Puedes ir también a los artículos 1 y 3.

¿Qué ventajas nos ofrece este modelo MVC en ASP.NET?

• Es extensible
• Es amigable con SEO (las url son muy sencillas, e implementan las acciones y parámetros de forma natural, facilitando su acceso mediante buscadores) y REST
• Nos da un enorme control sobre la salida
• Nos da un enorme control sobre el flujo
• Nos separa de forma natural las responsabilidades
• Facilita la prueba de nuestras aplicaciones de formas que en el mundo WebForms no podríamos ni imaginar.
• Se sigue basando en todo el framework existente ASP.Net (masterpages, membership, etc.)
• Se integra con el funcionamiento natural de la web, sin metáforas que nos acaben complicando la vida en cuanto tratamos de realizar cosas más complejas
• Estabilidad y fiabilidad: se basa sobre el más que probado framework asp.Net, e integra casi cualquier elemento que nos pueda hacer falta
• Facilita los cambios (sí, esta vez de verdad, de forma muy superior a como se facilita en las aplicaciones N-tier)
• Facilita separar el trabajo de los diseñadores, que pueden editar directamente la capa de presentación, sin tener que pasar como ocurre con Silverlight con herramientas específicas de diseño.
• Se integra de forma natural con jQuery

¿Debemos migrar las aplicaciones Webform existentes?
No. Para nada. En todo caso, habría que evaluar si los problemas y cambios que nos solicitan en el mantenimiento de las aplicaciones antiguas, nos justifican el cambio.
Lo que sí es cierto, es que la migración a MVC ofrece de forma exponencial unos enormes beneficios de cara al mantenimiento.

ASP.NET MVC (I) Introducción

Introducción
Hoy vamos a ver una introducción a lo que espero sea una larga serie de artículos sobre ASP.NET MVC.
Podéis saltar directamente a las partes 2 y 3
Aquellos que vengáis del mundo Java prácticamente veréis a MVC como un estándar del día a día. Pero en el mundo .Net, no es así.

El problema es que en .Net hemos sufrido de la obsesiva directriz de Microsoft en el sentido de OCULTAR la complejidad y la esencia de las cosas, encapsulándolo todo en nuevas metáforas supuestamente más sencillas. Eso ha funcionado muy bien, consiguiendo en el modelo ASP.NET Webforms una forma relativamente simple de construir aplicaciones Web. Pero no deja de ser una abstracción, una metáfora. Cuando intentamos bajar al nivel del código Javascript es cuando realmente vemos que la metáfora de los WebForms se cae con su propio peso y nos ha estado ocultando una realidad compleja, pero que en otras tecnologías como Java, se maneja de forma natural.

Desde hace ya algún tiempo, ASP.NET MVC se ha introducido como una forma de volver a las raíces, de resolver las dos principales problemáticas que existían en los desarrollos web:

• No ocultar la naturaleza de la web mediante falsas metáforas, que realmente nos complicaban mucho más la vida, como el uso de ViewState, etc.
• Los flujos de las aplicaciones no están integrados de forma natural en las estructuras y arquitecturas de los webforms. Los webforms están diseñados para ser sencillos de implementar desde el punto de vista de los WinForms (pantallas de escritorio). Pero no constituyen una forma natural de implementar y separar la visualización de los datos, de lo que es el negocio.

El modelo MVC ante todo se basa en la estructura del flujo de nuestra aplicación Web. Representa de forma natural una vista por pantalla (o tipo de pantalla), e implementa acciones que no son sino las acciones de nuestras pantallas.

¿Cómo funciona MVC?
El patrón que se usa en MVC de ASP.NET es el de Front Controller.
Al controlador le llegan peticiones, que pasan por un mecanismo de enrutamiento. El enrutador decide qué controlador debe dispararse, ese controlador es el que da paso a las acciones e interactúa con el modelo, dando como resultado una vista.

El enrutamiento se encuentra dentro del espacio de nombres System.Web.Routing. Se trata de un espacio de nombres independiente de ASP.NET MVC, por lo que las personas que utilicen ASP.NET clásico (el de webforms), pueden tener también acceso a ese espacio de nombres.

Enrutado
La esencia de MVC dentro de ASP.NET se encuentra en el enrutado. Para ello, en el archivo Global.asax se define una tabla de rutas, una colección de rutas (RouteTable). Esa tabla lleva una ordenación, y el comportamiento vendrá definido por dicho orden (debe de ponerse el comportamiento más restrictivo siempre antes). Además, este enrutado permite restricciones (por ejemplo, en función de una clase específica definida por nosotros, o bien a través de expresiones globales).

Definición de rutas
La definición de rutas se hace mediante patrones. El patrón más común es:
{Controlador}/{acción}{parámetro}
Esto hace que la forma más habitual de navegar en una aplicación MVC sea mediante url's del estilo:
http://misitioweb/controlador/accion/parametro

Para definir una ruta por código sería algo así como:
var route = new Route("{controller}/{action}/{param}",new MvcRouteHandler());
class Route: RouteBase{
     //definición de la ruta
     string Url
     RouteValueDictionary Defaults //valores por defecto
     RouteValueDictionary Constraints //permite definir restricciones
     RouteValueDictionary DataTokens //permite asignar metadatos donde guardar información adicional 
     IRouteHandler RouteHandler
}

Bueno, ya vale para una primera introducción.
Para saltar a la segunda parte de este post, clic aquí.