ASP.NET MVC Q&A: ¿Como reciben parámetros los controladores?

Este es el segundo post de la serie que nace a raíz de las preguntas que se me realizaron en el Webcast que di sobre ASP.NET MVC.

Estaba explicando la tabla de rutas por “defecto” de ASP.NET MVC, indicando que el primer valor era el controlador, el segundo la acción y el tercero un parámetro llamado id:

routes.MapRoute(
"Default", // Nombre de la ruta
"{controller}/{action}/{id}", // Formato de url /Controlador/Accion/Id
new { controller = "Home", action = "Index", id = UrlParameter.Optional } // Valores x defecto
);

Comenté que dada esa tabla de rutas una url /Home/Index/100 se mapeaba a l’acción Index del controlador Home con un parámetro id a valor 100 (parámetro que era opcional).

En el Webcast no comenté nada más… voy a ampliar el tema ahora, porque es realmente interesante.

1. Acciones y tabla de rutas

Vamos a aclarar algunos puntos que son fundamentales relativos a las acciones y la tabla de rutas:

  1. Las acciones se distinguen por su nombre, sin tener en cuenta sus parámetros. Eso significa que un controlador no puede definir dos veces la misma acción con parámetros distintos, salvo que se responda a verbos http distintos (p.ej. una acción responda a GET y otra a POST).
  2. La tabla de rutas mapea una URL a una única acción de un controlador.
  3. La tabla de rutas tiene una o más rutas, que se evalúan en orden. Cuando una URL hace matching con una ruta, se termina la evaluación.

Así el siguiente código es erróneo:

public class HomeController : Controller
{
public ActionResult Index()
{
return View();
}
public ActionResult Index(int id)
{
return View();
}
}

Uno podría pensar que la tabla de rutas enrutaría /Home/Index al método Index() sin parámetros y /Home/Index/100 al método Index() que acepta un entero, pero no. La tabla de rutas enruta tanto /Home/Index/ como /Home/Index/100 a la acción Index. Luego el framework cuando va a invocarla se encuentra con dos métodos que la implementan y da un error: The current request for action ‘Index’ on controller type ‘HomeController’ is ambiguous between the following action methods: System.Web.Mvc.ActionResult Index() on type MvcControllerParams.Controllers.HomeController System.Web.Mvc.ActionResult Index(Int32) on type MvcControllerParams.Controllers.HomeController

2. Parámetros opcionales en las rutas

¿Y que ocurriría con el siguiente código?

public class HomeController : Controller
{
public ActionResult Index(int id)
{
return View();
}
}

La tabla de rutas enruta /Home/Index/100 a dicha acción y el parámetro id vale 100… pero que ocurre si entramos /Home/Index?

Pues que da error: El parámetro id está declarado como opcional en la ruta, eso significa que puede no aparecer en la url. Así pues la url /Home/Index es válida y se enruta a la acción Index. Y cuando el framework se encuentra que quiere pasarle un valor al parámetro id, no puede porque no hay parámetro id en la url y int no es nullable. El mensaje de error que da es:

The parameters dictionary contains a null entry for parameter ‘id’ of non-nullable type ‘System.Int32’ for method ‘System.Web.Mvc.ActionResult Index(Int32)’ in ‘MvcControllerParams.Controllers.HomeController’. An optional parameter must be a reference type, a nullable type, or be declared as an optional parameter.

La solución? Pues declarar que el parámetro id sea nullable:

public class HomeController : Controller
{
public ActionResult Index(int? id)
{
return View();
}
}

Fíjate en el uso de int? (que es la sintaxis que da C# para usar Nullable<int>).

Otra posible opción seria modificar la tabla de rutas para que en lugar de declarar el parámetro simplemente como opcional, asignarle un valor por defecto:

routes.MapRoute(
"Default", // Route name
"{controller}/{action}/{id}", // URL with parameters
new { controller = "Home", action = "Index", id = 0 } // Parameter defaults
);

Fíjate que donde antes ponía id = UrlParameter.Optional ahora pone id = 0. La diferencia es sutil pero importante: antes si id no aparecía el framework asumía que no tenía valor, ahora si el parámetro no aparece el framework le asigna un valor por defecto de 0. Así, ahora en el controlador podemos volver a usar int en lugar de Nullable<int> (int? en c#).

El “pero” de esta opción es que no puedes distinguir entre /Home/Index y /Home/Index/0. Ambas URLs invocan la acción Index con el valor id=0.

Bien… ¿y que ocurrirá si entro la url /Home/Index/eiximenis? Pues que la tabla de rutas mapeará esta url a la acción Index y cuando el framework vaya a invocarla intentará convertir “eiximenis” a int y dicha conversión devolverá null al no ser posible. Así:

  • Si teníamos Index(int id) el framework dará error, indicando que no puede asignar “null” a int.
  • Si teníamos Index (int? id) recibiremos el valor null en el parámetro id. Efectivamente en este caso es lo mismo /Home/Index que /Home/Index/eiximenis

Si en lugar de declarar la acción con un parámetro int la declaro que recibe una cadena:

public ActionResult Index(string id)
{
return View();
}

Todo es mucho más sencillo:

  • /Home/Index –> Invoca Index() con id = null
  • /Home/Index/100 –> Invoca Index() con id = “100”
  • /Home/Index/eiximenis –> Invoca Index() con id=”eiximenis”

3. Acciones sin parámetros opcionales

Vamos a cambiar de nuevo la tabla de rutas para que quede:

routes.MapRoute(
"Default", // Route name
"{controller}/{action}/{id}", // URL with parameters
new { controller = "Home", action = "Index" } // Parameter defaults
);

Fíjate que hemos eliminado la parte donde ponía id = UrlParameter.Optional. Así ahora el parámetro id es obligatorio en la ruta.

La url /Home/Index/eiximenis nos invoca la acción Index() con id=”eiximenis” pero que hace la url /Home/Index? Pues devuelve un 404. ¿Por que? Bien, cuando una URL no satisface ninguna de las entradas de la tabla de rutas, el framework devuelve un 404 para indicar que la URL no se corresponde a ningún recurso. En nuestro caso la tabla de rutas tiene una sola entrada que obliga que las urls tengan la forma /controlador/accion/id. Y dado que id no se ha declarado opcional ni se le ha dado ningún valor por defecto, debe aparecer explícitamente en la URL. Como en nuestro caso no aparece, la URL /Home/Index no cumple esta entrada en la tabla de rutas y por eso recibimos el 404.

4. Rutas con más de un parámetro

La pregunta explícita que me hicieron en el Webcast fue “Y se puede pasar más de un parámetro”? Mi respuesta en aquel momento fue simplemente que sí, añadiendolos a la tabla de rutas:

routes.MapRoute(
"Default", // Route name
"{controller}/{action}/{id}/{desc}", // URL with parameters
new { controller = "Home", action = "Index",
id = UrlParameter.Optional, desc = UrlParameter.Optional } // Parameter defaults
);

Ahora la ruta tiene dos parámetros (ambos opcionales) id y desc.

En el controlador definimos la acción con los dos parámetros:

public ActionResult Index(string id, string desc)
{
return View();
}

Tal y como lo tenemos:

  • /Home/Index –> Invoca a Index con id=null y desc=null
  • /Home/Index/eiximenis –> Invoca a Index con id=”eiximenis” y desc=null
  • /Home/Index/eiximenis/edu –> Invoca a Index con id=”eiximenis” y desc=”edu”

De esta manera podemos pasar más de un parámetro a los controladores.

5. Otros parámetros (querystrings,…)

Bueno… vamos a liarla un poco más! Tal y como lo tenemos que ocurre con la url /Home/Index/eiximenis?desc=edu ?

Pues veamos: La tabla de rutas no usa la querystring, así que para la tabla de rutas es como si hubiesemos entrado /Home/Index/eiximenis, lo que se mapea a la acción Index. Luego cuando el framework va a invocar dicha acción:

  • Pone el valor de id a “eiximenis” (primer valor de la url)
  • El valor de la ruta para desc és null (recordad: la tabla de rutas no entiende de querystring). Entonces se analiza la querystring y el framework ve que el controlador acepta otro parámetro llamado desc y que en la querystring aparece dicho parámetro, así que le asigna valor.

Así por lo tanto, la url /Home/Index/eiximenis?desc=edu llama a l’acción Index con el valor de id a “eiximenis” y el valor de desc a “edu”.

Fijaos pues que las urls /Home/Index/eiximenis/edu y /Home/Index/eiximenis?desc=edu son equivalentes, puesto que ambas terminan llamando a la misma acción con los dos parámetros… pero que sean equivalentes no quiere decir que sean indistinguibles. Desde el controlador podemos saber si los parámetros nos vienen via ruta o bien via querystring:

public ActionResult Index(string id, string desc)
{
var routedesc = this.RouteData.Values["desc"];
return View();
}

El valor de routdesc será “edu” si venimos por la url /Home/Index/eiximenis/edu y null si venimos por la url /Home/Index/eiximenis?desc=edu

Nota: Todo lo que hemos dicho sobre la querystring aplica también a parámetros POST.

6. Bindings

Y vamos ya con la última… Imagina que tenemos una clase así:

public class FooModel
{
public string id { get; set; }
public string desc { get; set; }
}

Y declaramos nuestra acción para que reciba, no dos strings sinó un objeto FooModel:

public ActionResult Index(FooModel m)
{
return View();
}

Ahora en este caso la url:

  • /Home/Index –> Invoca a Index() con un objeto FooModel con id=null y desc=null
  • /Home/Index/eiximenis –> Invoca a Index() con un objeto FooModel con id=”eiximenis” y desc=null
  • /Home/Index/eiximenis/edu –> Invoca a Index() con un objeto FooModel con id=”eiximenis” y desc=”edu”
  • /Home/Index/eiximenis?desc=edu –> Invoca a Index() con un objeto FooModel con id=”eiximenis” y desc=”edu”

Que te parece? El framework es capaz de convertir los parámetros (vengan de la ruta o del querystring) en el objeto que espera la acción, instanciando sus propiedades!

Y bueno… vamos a dejarlo aquí por el momento 🙂 Espero que ahora tengáis un poco más claro como funciona el “paso de parámetros” a los controladores.

Un saludo a todos! 😉

Una postdata para quien quiera profundizar

Si quieres profundizar en este tema, antes que nada ten presente los siguientes puntos:

  • A través de la tabla de rutas el framework decide que acción implementa la URL
  • Antes de invocar una acción, los Value Providers entran en acción, procesando los valores de la request. Los valores de la request pueden estar en:
    • RouteData (puestos por la tabla de rutas)
    • QueryString
    • POST
    • Cualquier otro sitio (p.ej. cookies). Se pueden crear value providers propios.
  • Antes de invocar la acción, el ModelBinder entra en acción: coge los valores que han procesado los Value Providers y los intenta mapear a los parámetros de la acción.
  • Se invoca la acción del controlador.

Ahora algunos links:

2 comentarios sobre “ASP.NET MVC Q&A: ¿Como reciben parámetros los controladores?”

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *