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).