Introduccio n a ASP.

NET MVC
Breve historia del desarrollo web
Demos un pequeo y somero repaso al desarrollo de aplicaciones web. Por supuesto este
apartado no intenta ser un reflejo detallado de la historia del desarrollo web, simplemente una
introduccin que nos permita situarnos y tener un poco de perspectiva.
Empecemos all por el 1993... En aquel entonces se empezaba a hacer evidente la necesidad
de construir pginas web dinmicas, es decir que los servidores web pudiesen servir pginas
que no existiesen fsicamente como archivos HTML. Hasta entonces el nico dinamismo era el
que incorporaba HTML, bsicamente formularios y poca cosa ms. As un equipo de trabajo de
NCSA defini el estndar CGI (Common Gateway Interface) para permitir llamar a procesos
desde un servidor web y devolver como respuesta http la salida generada por dichos procesos.
CGI fue el primer paso para la creacin de aplicaciones web, aunque tena un problema
principal: cada invocacin del proceso externo implicaba precisamente esto, crear un proceso
nuevo en el sistema operativo. Una tarea extremadamente costosa que en muchos casos se
llevaba la mayor parte del tiempo de proceso. Para evitar este punto se desarrollaron
alternativas como permitir que el proceso que se ejecute no sea un proceso externo si no
cdigo en una librera que se ejecutase dentro del navegador web (mdulos de Apache, filtros
ISAPI de IIS, plugins NSAPI de Netscape,...), o bien reutilizar el mismo proceso para varias
llamadas (FastCGI).
El siguiente punto de inflexin fue la aparicin de Personal Home Page Tools, el embrin de lo
que ahora conocemos como PHP, cuya primera versin apareci all por el 1995. PHP ofreca
una solucin al otro problema de CGI, que era que el proceso externo deba generar todo el
HTML de salida que se enviaba al navegador. PHP permita incorporar cdigo de servidor
dentro de cdigo HTML. Cuando se invocaba a una pgina que contena esas funciones
propias, el cdigo PHP incorporado se interpretaba y generaba cdigo HTML que es el que se
mandaba al cliente (navegador) en lugar del cdigo PHP. De esta manera las pginas eran una
mezcla de cdigo HTML y cdigo de servidor (PHP). Eso fue una gran revolucin porque
simplificaba mucho el desarrollo de pginas web dinmicas.
Avancemos un ao ms para situarnos en 1996. Por aquel entonces Microsoft lanzaba Active
Server Pages (ASP), lo que podramos considerar su respuesta a PHP. ASP segua la misma
filosofa que PHP, pero usando una versin reducida de su muy popular Visual Basic conocida
como Visual Basic Scripting Edition (VBScript). Pero las ideas bsicas son las mismas: cdigo de
cliente mezclado con cdigo de servidor (en VBScript) que es interpretado para generar el
HTML final que se enva al navegador final.
La siguiente revolucin vino un par de aos despus, a finales de este mismo ao (1998) de la
mano de Sun Microsystems y su relativamente nueva plataforma Java. Por aquel entonces
Java, que estaba viviendo sin excesiva gloria en el mundo de los applets daba su salto a la
conquista del mundo de servidor con la aparicin de la especificacin 2.1 de los Servlets.
Aunque en el fondo esa es la tercera especificacin de Servlets (antes hubo la 1.0 y la 2.0) esta


es la primera oficial. Servlets era como una especie de CGI (con muchas mejoras) pero hecho
en Java. Para lo que nos atae con Servlets de nuevo volvemos atrs en lo que se refiere al
desarrollo ya que ahora debemos generar otra vez todo el cdigo HTML desde un programa
externo (el Servlet). Pero poco despus de la aparicin de la especificacin Servlet 2.1, Sun
tena preparado un autntico bombazo: la presentacin de Java Server Pages (JSP). JSP ofreca
el esquema de desarrollo de PHP y ASP (cdigo de servidor mezclado con cdigo HTML de
cliente) pero con un detalle importantsimo: cada pgina JSP era traducida de forma
transparente a un Servlet, que era el que luego era ejecutado. Esto era una mejora brutal
respecto a PHP y ASP ya que los Servlets no eran interpretados: eran compilados (a bytecode,
cierto, en una mquina virtual, cierto. Pero an y as mucho ms rpido que interpretar el
cdigo). La creacin del servlet a partir de la JSP y su compilacin (en caso de ser necesaria)
eran procesos que se ejecutaban automticamente. En mi opinin por aquel entonces JSP
representaba el modelo tcnicamente ms avanzado que exista, comparado con PHP o ASP
todo eran ventajas (compilacin vs interpretacin, lenguaje orientado a objetos vs lenguajes
de scripting) y sin duda JSP fue uno de los pilares del xito de Java en su conquista del mundo
del servidor.
Vaymonos ahora un ao atrs hacia el 1997 y fijmonos en Redmond porque en Microsoft se
estaban cociendo cosillas interesantes... Por aquel entonces Microsoft ya estaba pensando en
como poda ser la siguiente generacin de desarrollo de aplicaciones web y sacaron un
prototipo llamado XSP desarrollado en Java. Posteriormente decidieron no usar Java
(seguramente el conflicto entre Sun y Microsoft tuvo un peso decisivo en esto) e implementar
una nueva plataforma y en el 2000 presentaban la beta de ASP+ y del .NET Framework.
Posteriormente ASP+ se renombr a ASP.NET y a principios del 2002 apareca ASP.NET 1.0
como parte del lanzamiento de .NET Framework 1.0. ASP.NET fue una revolucin al presentar
un modelo de desarrollo totalmente nuevo en aplicaciones web. En lugar de mezclar cdigo de
servidor con cdigo HTML, en ASP.NET se optaba por un modelo ms cercano al de
aplicaciones de escritorio (que tanto xito haba cosechado con Visual Basic 6): en un entorno
RAD el desarrollador dispona controles, estableca propiedades y mediante eventos enlazaba
cdigo de servidor. De hecho el desarrollador no tena que tratar (ni en teora conocer) HTML:
todo el cdigo se generaba a partir de los controles que se pusieran en la pgina ASP.NET.
Microsoft llam a las pginas ASP.NET webforms, y as son conocidos hoy en da.
Y ahora tenemos que dar un salto de varios aos para encontrarnos con otra revolucin digna
de ser mencionada (por supuesto que en todos estos aos hubo mejoras destacables, como
que PHP se hizo orientado a objetos e incluso compilado, o versiones nuevas de JSP y ASP.NET,
pero ningn player nuevo)... Nos situamos en el 2007 donde apareca la versin 2.0 de Ruby on
Rails (RoR) y con ella un revuelo digno de la explosin de una supernova. RoR contiene todas
las herramientas necesarias (lo que los anglosajones llaman full-stack) para el desarrollo de
aplicaciones web. Y porque revolucion RoR el desarrollo de aplicaciones web? Por varias
razones, pero destacaramos la facilidad y rapidez en crear una aplicacin web (aplicando
tcnicas de scaffolding), el que no eran necesarias ms herramientas que el propio RoR y por
inducir a las buenas prcticas obligando a usar desde el principio el patrn Modelo-Vista-
Controlador (MVC). No es que RoR fuese la primera implementacin de MVC para web (p.ej.
Struts ya exista sin ir ms lejos y desde hace aos), ni mucho menos, pero s que era la


primera vez que dicho patrn apareca como parte integral de un framework de desarrollo de
aplicaciones web.
La popularidad de RoR hizo que Microsoft se plantease algunas cosas al respecto del desarrollo
de aplicaciones Web. Aunque es posible aplicar MVC en webforms es algo que no est
incorporado de serie en el propio modelo de desarrollo ni tampoco es sencillo ni intuitivo de
realizar. Adems el modelo de webforms estaba a empezar a dar ciertos sntomas de
agotamiento.
Por ello en Microsoft vieron clara la necesidad de ofrecer un framework alternativo a
webforms, que corriese bajo ASP.NET (para aprovecharse de todos los aspectos transversales
de ASP.NET como seguridad, sesin, aplicacin, autenticacin,...). Y as a finales del 2007
apareca la CTP de ASP.NET MVC... y tras cinco previews y una beta apareca la versin final en
el 2009. A partir de este momento el ciclo de desarrollo se aceler bastante hasta llegar al
punto de la aparicin de la versin 3.0 en 2011 y de la beta de la versin 4 en febrero del 2012.
Y por supuesto que queda claro: hoy en da es posible desarrollar usando MVC con cualquiera
de las tecnologas aqu mencionadas (y evidentemente con algunas no mencionadas).
ASP.NET MVC versus Webforms
Cuando Webforms apareci, all por el principio de los 2000, el ecosistema de aplicaciones
web era muy distinto del actual y la verdad es que Webforms encajaba muy bien con la tpica
aplicacin de por aquel entonces: entrada de datos, envo de datos, y nueva pantalla de
resultado (o entrada de ms datos). Ajax estaba muy lejos todava, aunque el embrin
tecnolgico de Ajax se invent en 1999 (y fue casualmente Microsoft) el propio trmino no se
acu hasta el 2005 y la primera especificacin oficial por parte del W3C no lleg hasta un ao
despus.
A medida que las aplicaciones Web ganaban en complejidad y Ajax se iba popularizando, el
modelo de Webforms iba perdiendo fuelle. All por el 2008 los sntomas de agotamiento eran
cada vez ms evidentes. Y entonces los primeros coletazos de HTML5 empezaron por redefinir
las aplicaciones web y de repente el procesamiento en cliente, usando javascript y frameworks
como jQuery, empezaba a cobrar importancia y el ciclo peticin -> respuesta tpico se
empezaba a romper incorporando Ajax e incluso notificaciones push. Este escenario, que
adems evolucion rpidamente, pill a Webforms con el paso cambiado: con un ciclo de vida
complejo y basado en peticin -> respuesta, el paso a Ajax y aplicaciones muy dinmicas no era
sencillo. Muchos desarrolladores ASP.NET se quejaban de la complejidad de realizar este tipo
de aplicaciones en Webforms, que les obligaba a romper la abstraccin de HTML/HTTP que da
sentido a Webforms. Y aunque Microsoft hizo mejoras muy importantes al respecto en .NET
Framework 4 (Visual Studio 2010) la sensacin de que Webforms se estaba agotando estaba
ah (y ah sigue). Quede claro que Microsoft no abandona Webforms, de hecho en el
framework 4.5 vienen con interesantes novedades, pero s que ofrece una alternativa:
ASP.NET MVC.
A diferencia de Webforms, que abstrae el desarrollador de HTTP e incluso de HTML, ASP.NET
MVC vive mucho ms cerca de la web. Eso significa que de entrada la curva de aprendizaje de
ASP.NET MVC es superior a la de Webforms, tan solo porque los conceptos iniciales para


empezar a desarrollar con el framework son superiores: es necesario conocer el
funcionamiento de http y es necesario conocer HTML, Javascript (y preferiblemente CSS).
ASP.NET MVC es un framework destinado a desarrolladores web que se espera que conozcan
las tecnologas y lenguajes asociados a la web. No est destinado a desarrolladores
generalistas o de cliente que tengan una necesidad puntual de realizar una aplicacin web. Eso
puede parecer una perogrullada para los desarrolladores de PHP o JSP (a quienes se les
suponen los mismos conocimientos), pero es una situacin nueva para muchos desarrolladores
de Webforms (Si vienes de Webforms, estate tranquilo: a lo largo de este curso iremos
explicando todos los conceptos de HTTP necesarios para ir siguiendo el curso de ASP.NET
MVC).
Este modelo de desarrollo tan distinto ya se ve de buenas a primeras: en ASP.NET MVC no hay
vista de diseo, no hay controles, no establecemos propiedades, no asignamos eventos a
cdigo de servidor. Si tenemos que editar una pgina (aunque lo llamamos vista) trabajaremos
directamente con el cdigo HTML, mezclando cdigo de servidor en aquellos lugares donde
sea necesario (al igual que se hace en PHP, JSP o el ASP clsico). Esto ha supuesto muchas
crticas a ASP.NET MVC, diciendo que es una vuelta a los 90 y que las vistas terminan siendo
una mezcla catica de cdigo de servidor y de cliente (lo que se conoce como tag soup). Nada
ms lejos de la realidad, quien realiza esas crticas suele hacerlas desde el desconocimiento: si
el cdigo de ASP.NET MVC se parece al de ASP clsico es porque se est aplicando mal el
patrn MVC. Porque s, ASP.NET MVC nos obliga a aplicar el patrn MVC pero aplicarlo bien es
responsabilidad nuestra :)
Veamos ahora en que consiste el patrn MVC, si conoces Struts, has usado algn framework
de MVC para PHP (como CodeIgniter) o evidentemente conoces RoR entonces ya estars
familiarizado con dicho patrn...
El patrn MVC
Empezaremos diciendo que este patrn no es un invento de Microsoft, ni de RoR ni tan
siquiera de Sun Microsystems para java. Es anterior al 2000, de hecho es anterior al 1990. Es
ms: es anterior a la web, pues data del 1979 y el primer lenguaje que lo incorpor fue
Smalltalk para el desarrollo de interfaces de usuario.
Como su nombre indica divide la responsabilidad de la aplicacin en tres elementos: el
Modelo, la Vista y el Controlador:

Ilustracin 1: Patrn MVC (fuente: Wikipedia)


Modelo: Representa los datos y lgica de negocio asociada de la aplicacin. Es decir si
estamos creando una aplicacin para reservar viajes online, todo el cdigo de acceso a
datos y validacin de las reservas estar en el modelo.
Vista: Transforma el modelo en una representacin grfica. Por supuesto ninguna vista
transforma el modelo entero sino una parte de l. Por ejemplo una vista puede
mostrar por pantalla la lista de destinos posibles para los viajes. Las vistas son tontas,
es decir no tienen ninguna lgica de negocio. Se limitan a mostrar los datos que les son
proporcionados.
Controlador: Recoge la interaccin del usuario y trata con el modelo (para obtener
datos y/o actualizarlos) y selecciona la vista necesaria para representar dichos datos.
Como se mapea el patrn MVC a ASP.NET MVC?
Veamos ahora como los elementos del patrn MVC se mapean a ASP.NET MVC
1. Una peticin http es enviada al controlador.
2. El controlador examina la peticin y
a. Interacciona con el modelo (recuperando datos, guardndolos,
validndolos,...)
b. Selecciona la vista que debe enviarse al cliente y le manda los datos que esta
debe mostrar
3. La vista es mostrada en el cliente.
Cuando en el punto (2.b) el controlador recupera datos del modelo y los manda a la vista (por
ejemplo la lista de destinos vlidos para un viaje) el controlador puede preparar los datos para
que sea ms fcil mostrarlos (p.ej. puede ordenarlos alfabticamente). Se suele llamar
viewmodel (modelo de vista) al conjunto de datos que el controlador manda a la vista ya bien
masticados, por lo que podemos asumir que la tarea habitual de una vista es simplemente
representar los datos contenidos en su viewmodel. La vista debera ser agnstica sobre donde
provienen los datos. Recordad vistas tontas: No hacen nada salvo mostrar su viewmodel.
Tambin, y aunque ya entraremos en ello, aunque hemos hablado de vistas que terminan
mandando HTML al navegador, por supuesto es posible enviar tan solo porciones de HTML
(para Ajax) o bien no enviar HTML en absoluta (y mandar otras cosas como cdigos http, xml o
lo que sea).
Elementos de ASP.NET MVC
Aunque iremos profundizando a lo largo del curso veamos un primer esbozo del ciclo de una
vida de una peticin en ASP.NET MVC.
1. La peticin es capturada por ASP.NET MVC y se decide que controlador es el que debe
procesarla (pueden haber varios controladores distintos).
2. ASP.NET MVC crea una instancia del tipo de controlador seleccionado por (1).
3. Se invoca la accin correspondiente en el controlador. La accin es el mtodo del
controlador que gestiona la peticin (un controlador puede tener varias acciones).
a. Si la peticin contiene parmetros esos son pasados a la accin siguiendo
ciertas convenciones.


4. Se ejecuta el cdigo de la accin (mtodo) del controlador. Dicho cdigo interacciona
con el modelo y crea un resultado que usualmente es devolver una vista al cliente.
5. Se ejecuta el resultado creado por la accin. En la mayora de ocasiones eso significa
crear una vista, pasarle el viewmodel, ejecutar la vista (que genera HTML) y enviar el
HTML enviado al cliente
a. Pero puede significar otras cosas como enviar un cdigo http 404, una imagen
en binario, un http 301...
As pues toda peticin es enrutada a una accin de un controlador. Dicha accin ejecutar
cdigo, usualmente interaccionar con el modelo y devolver un resultado de accin. El
framework ejecutar dicho resultado de accin que generalmente ser ejecutar una vista para
que muestre determinados datos.
El fichero ASP.NET MVC Pipeline.pdf contiene el diagrama completo de una peticin de
ASP.NET MVC que realiz Simeone Chiaretta
1
. Se trata de los cinco puntos que acabamos de
enumerar (con mucho ms detalle). No te asustes si no entiendes apenas nada: el objetivo del
curso es que al terminar te conozcas ese diagrama al dedillo y, por supuesto, lo entiendas
perfectamente.
Vamos a aclarar algunos otros conceptos adems de los que ya conocemos.
La tabla de rutas
Se trata de uno de los elementos ms importantes (y muchas veces ignorados) del framework
de ASP.NET MVC. La tabla de rutas es la que determina que accin de que controlador debe
invocarse a partir de una peticin http. De momento no entraremos en ms detalles, ms
adelante hablaremos ampliamente de la tabla de rutas, solo comentar que la tabla de ruta
usa tan solo la URL de la peticin y el verbo http para seleccionar la accin y el controlador.
Ningn otro elemento existente en la peticin es considerado.
La tabla de rutas por defecto de ASP.NET MVC enruta las URLs en la forma
http://servidor/controlador/accion. As la URL http://localhost/Home/Index ser enrutada a la
accin Index del controlador Home. Si dicho controlador no existe o bien existe pero no tiene
la accin Index, se devuelve un 404 (not found) al cliente.
Model Binder
El Model Binder es el encargado de recoger los datos de la peticin http y pasarlos a la accin
del controlador. Recuerda que las acciones son mtodos pblicos del controlador y la forma
que tienen de recibir datos es la misma que tiene cualquier funcin: declarando parmetros.
Entonces el Model Binder es el encargado de rellenar los parmetros de la accin a partir de la
informacin contenida en la peticin http.
Resultado de accin
Hasta ahora hemos hablado de MVC diciendo que al final se devuelve una vista al cliente con
el HTML generado. Eso no es del todo cierto. En la gran mayora de casos se devuelve una
vista, ya que estamos creando una aplicacin web y las aplicaciones web bsicamente
devuelven HTML pero es posible devolver otras cosas al cliente: cdigos http como 301, 404,

1
http://codeclimber.net.nz/


500, u otros content-type como imgenes, un fichero comprimido para descargar, un objeto
serializado en json o un xml (por poner algunos ejemplos). A nivel del framework todos estos
posibles resultados quedan abstrados por la clase ActionResult. En efecto: todas las acciones
deben devolver un ActionResult y el tipo de ActionResult define exactamente lo que se
devuelve al cliente. El ActionResult ms habitual es ViewResult que significa devolver una vista,
pero existen otros y adems podemos crearnos los nuestros propios.
La primera aplicacin ASP.NET MVC
Nota: Ver el vdeo.
Convenciones sobre configuracin
ASP.NET MVC sigue el estilo de convention over configuration que significa que en lugar de
estar configurando determinados aspectos del framework se asumen unas convenciones de
forma que basta con seguir dichas convenciones para que todo funcione bien. Las
convenciones ms importantes son las siguientes:
1. El nombre de la clase que implementa un controlador es el nombre del controlador
con el sufijo Controller. As p.ej. la clase HomeController implementa el controlador
Home.
2. Las acciones son mtodos pblicos de la clase que implementa el controlador. Todo
mtodo pblico es, por defecto, una accin de dicho controlador.
3. El nombre de la accin es el nombre del mtodo pblico que la implementa.
4. Las vistas se encuentran en una subcarpeta XXX dentro de la carpeta /Views, siendo
XXX el nombre del controlador asociado. As las vistas devueltas por cualquier accin
del controlador Home estarn en /Views/Home.
5. El nombre de una vista ser por defecto el mismo nombre que la accin. As si la
accin Index del controlador Home quiere devolver una vista, dicha vista se llamar
Index (y por la convencin 4 estar en /Views/Home).
Nota: La tabla de rutas estndar (que enruta las URLs con forma
http://servidor/controlador/accion) no es una convencin. Realmente ASP.NET MVC no tiene
ninguna tabla de rutas estndar, pero llamamos tabla de rutas estndar a la que genera por
defecto Visual Studio en todo proyecto ASP.NET MVC.