ASP.NET MVC: ValueProviders

Hola! Hoy quiero comentar un aspecto de ASP.NET MVC2 que no sé hasta que punto es conocido, y son los llamados Value Providers.

Disclaimer: Este post será largo y puede ser un poco denso y asumo conocimientos básicos de ASP.NET MVC. Tampoco tengas reparos en leerte este post en más de un dia si quieres… había pensado dividirlo en dos posts, pero al final he preferido meterlo todo en uno.

Si habéis trabajado un poco con ASP.NET MVC, sabréis que si tenéis un controlador con esta acción:

[HttpPost()]
public ActionResult Create(Producto p)
{
// Hacer algo con producto
return View();
}

ASP.NET MVC es capaz de hacer binding entre los parámetros de la Request y las propiedades de la clase Producto para instanciar un objeto Producto para tí y pasarlo al controlador.

Es decir, si la clase producto está definida como:

public class Producto
{
public int Codigo { get; set; }
public string Nombre { get; set; }
public int Precio { get; set; }
}

Y la Request tiene estos campos, ASP.NET MVC hace el binding por nosotros… P.ej. si usamos un formulario como el siguiente para enviar los datos:

<form action="/Productos/Create" method="post">
<fieldset>
<input id="Codigo" name="Codigo" type="text" value="" />
<input id="Nombre" name="Nombre" type="text" value="" />
<input id="Precio" name="Precio" type="text" value="" />
<input type="submit" value="Create" />
</fieldset>
</form>

La Request tiene los campos “Codigo”, “Nombre” y “Precios” (los name de los input). Al enviarse el formulario genera una Request con los siguientes datos POST (se pueden ver fácilmente usando firebug):

Content-Type: application/x-www-form-urlencoded

Content-Length: 31

Codigo=1&Nombre=Silla&Precio=12

La última línea es la que tiene los campos con los valores, que son usados por ASP.NET MVC para realizar el binding con la clase Producto.

El responsable de recoger los valores y realizar el binding con el modelo es el ModelBinder pero no es reponsabilidad del ModelBinder saber donde están los valores. P.ej. haced una prueba… Si al formulario anterior le quitáis uno de los campos (p.ej. el campo Precio) y modificáis el action del <form> para que quede <form action=”/Productos/Create?Precio=10” method=”post> y realizáis la petición veréis que sigue funcionando.

En este caso si miramos con firebug la petición, no tiene el parámetro post “Precio”:

Content-Type: application/x-www-form-urlencoded

Content-Length: 21

Codigo=1&Nombre=Silla

Pero si que dicho parámetro está en la URL, que ahora es /Productos/Create?Precio=10. Pero esto no afecta al ModelBinder que es capaz de recoger el parámeteo con independencia de dónde se encuentre dentro de la Request. ¿Y cómo es posible? Pues gracias a los Value Providers.

Pero antes sigamos jugando un poco, para tener todas las piezas encima de la mesa… que ocurre si sin modificar el atributo action del tag <form> volvemos a añadir el <input name=”Precio”> al formulario? Es decir tenemos un formulario con los tres campos (Codigo, Nombre y Precio) pero además tenemos el campo Precio otra vez en la url (?Precio=100). Pueden ocurrir tres cosas:

  1. Que ASP.NET MVC de error, porque el campo “Precio” está repetido (una vez en la URL y otra en los parámetros POST) de la petición.
  2. Que tenga prioridad el valor del parámetro en la URL
  3. Que tenga prioriodad el valor del parámetro POST

Bien, lo que ocurre es que tiene prioridad el valor del parámetro POST. Es decir el valor de la propiedad Precio del objeto Producto que reciba el controlador será el que haya entrado el usuario y no el que se indica en la URL. Pero… ¿por que?

Cuando una petición es tratada por el framework, primero se pasa por una serie de value providers que inspeccionan cada uno dicha petición y guardan los valores que cada uno de ellos entiende. P.ej. existe un value provider para inspeccionar los valores POST y otro distinto para inspeccionar los valores de la URL. ASP.NET MVC mantiene una colección de value providers y pasa la request por todos ellos.

P.ej. asumamos en nuestro caso que tenemos una colección con dos value providers (luego veremos que esto no es exactamente así, pero me vale esa simplificación por ahora). Llamemosle PostValueProvider al primero y UrlValueProvider al segundo. Supongamos que nos llega la petición que hemos comentado:

  • Parámetros en la URL: ?Precio=100
  • Parámetros POST: Codigo=1&Nombre=Silla&Precio=12

La request pasa por el primer value provider (supongamos que es el PostValueProvider) que la inspecciona, ve que hay tres parámetros llamados Código, Nombre y Precio y se los guarda con sus respectivos valores. Luego la request pasa por el siguiente value provider, el UrlValueProvider que inspecciona la request y ve que hay un parámetro llamado Precio y se lo guarda junto con su valor.

Ahora es el turno del ModelBinder: el ModelBinder detecta que debe crear un objeto Producto que tiene tres propiedades: Código, Nombre y Precio, así que pregunta a los value providers por los valores de estos campos. Esta frase es la clave: pregunta a los value providers, no a un value provider en particular. Pongamos que cuando el ModelBinder necesita el valor del campo “Precio” se limita a preguntar simplemente el valor de dicho campo, y el ModelBinder espera que haya un sólo valor para dicho campo. Si como es el caso dos value providers han guardado el valor para dicho campo, sólo uno responde… cual? Pues el que esté primero en la lista de value providers que ASP.NET MVC mantiene. Ni más ni menos 🙂

Creación de un Value Provider propio

Como ya sabréis ASP.NET MVC es muy extensible, así que obviamente uno se puede crear sus propios Value Providers, para permitir tratar peticiones que tengan datos codificados de forma extraña o en otros sitios donde pueden estar los datos (p.ej. en cookies). Crear un value provider es muy simple, basta crear una clase que implemente la interfaz IValueProvider. Este interfaz define dos métodos:

  1. ContainsPrefix –> No se como explicar fácilmente lo que significa exactamente sin entrar en demasiados detalles sobre como funciona el ModelBinder, así que permitidme una simplificación. Este método devuelve si el value provider tiene valor para un campo en concreto. Es decir si el value provider tiene un valor para el campo “Precio” entonces ContainsPrefix(“Precio”) debe devolver true. Insisto: No es tan simple, pero para entender el concepto del post nos basta así.
  2. GetValue –> Devuelve el valor que se le pide. Es decir GetValue(“Precio”) devuelve el valor correspondiente al campo “Precio” que tenga este Value Provider. Este método sólo se llama si ContainsPrefix devuelve true.

Vamos a ver como podemos implementar un ValueProvider propio… P.ej. vamos a implementar un Value Provider que lea valores de los <appSettings> del web.config (de acuerdo, quizá no es brutalmente útil, pero como ejemplo servirá).

El código podría ser el siguiente:

public class AppSettingsValueProvider : IValueProvider
{
private Dictionary<string, ValueProviderResult> values;


public AppSettingsValueProvider()
{
values = new Dictionary<string, ValueProviderResult>();
foreach (string key in ConfigurationManager.AppSettings.AllKeys)
{
string appSetting = ConfigurationManager.AppSettings[key];
values.Add(key, new ValueProviderResult(appSetting, appSetting, CultureInfo.InvariantCulture));
}
}

public bool ContainsPrefix(string prefix)
{
return values.ContainsKey(prefix);
}

public ValueProviderResult GetValue(string key)
{
ValueProviderResult value;
values.TryGetValue(key, out value);
return value;
}
}

En el constructor se inicializa el diccionario values con los valores leídos de los <appSettings> del web.config. El método GetValue de IValueProvider, no devuelve un object con el valor directo del campo pedido, sinó que devuelve un ValueProviderResult una clase que tiene tres campos (rawValue, attemptedValue y culture).  El campo rawValue es lo que realmente se ha leído de la petición, mientras que el campo attemptedValue es el valor de rawValue convertido a una string. En mi caso dado que <appSettings> contiene ya string, tanto rawValue como attemptedValue tienen el mismo valor.

Bien! Ya tenemos un value provider… ahora ha llegado el momento de decirle a ASP.NET MVC que lo use… y aquí es donde debemos explicar la simplificación que hice antes 🙂

Factorías de Value Providers

Os acordáis cuando dije que ASP.NET MVC mantenía una colección de value providers y que pasaba la request a cada uno de ellos para que pudiesen procesarla y guardarse los campos necesarios? Dije que esto no era exactamente así, sinó una simplificación… Pues bien, la verdad es que ASP.NET MVC no mantiene una colección de value providers, sinó una colección de factorías de value providers.

Si te preguntas porque una factoría en lugar de guardar directamente los value providers… es para darte más control sobre como se crean los value providers: un value provider actúa sobre los datos de la petición actúal, por lo que por cada petición deben crearse todos los value providers de nuevo… La interfaz IValueProvider no define ningún mecanismo para pasarle la Request al value provider. Tampoco tenemos acceso a ningún tipo de contexto ni nada parecido… Piensa, si ASP.NET MVC debe crear los value providers a cada petición, cómo le pasa los datos de la request?

La solución pasa por usar factorías de value providers es decir, clases cuya única responsabilidad es crear los value providers a cada petición.

Veamos como sería nuestra factoría que cree objetos de nuestro AppSettingsValueProvider:

public class AppSettingsValueProviderFactory : ValueProviderFactory
{
public override IValueProvider GetValueProvider(ControllerContext controllerContext)
{

return new AppSettingsValueProvider();
}
}

Basta con derivar de ValueProviderFactory y redefinir el método GetValueProvider. En este méotdo tenemos acceso al ControllerContext que a su vez nos da acceso a la request http. Ahora si queréis pasáis la request http (o lo que queráis) al value provider.

Una vez tenemos la factoría debemos decirle a ASP.NET MVC que la use. Eso se hace registrando nuestra factoría usando la clase estática ValueProviderFactories:

ValueProviderFactories.Factories.Add(new AppSettingsValueProviderFactory());

Usualmente esto se coloca en el Application_Start de Global.asax.

Fijaos en un detalle: La factoría se crea sólo una vez (y la creamos nosotros, no el framework) y luego para cada petición se llama al método GetValueProvider de la factoría… método que también hemos hecho nosotros y donde se devuelve el value provider. De esta manera controlamos la creación de los value providers (lo que nos permitiría usar, si quisiéramos, mecanismos de inyección de dependencias).

Y listos! Ya estamos. Si modificamos la vista de datos para que no tenga el campo “Precio” (ni como POST ni como GET) y añadimos en el web.config:

<appSettings>
<add key="Precio" value="999"/>
</appSettings>

Veréis que el controlador recibe un Producto con el nombre y código que hayáis indicado y un Precio de 999. Dado que nuestra factoría se ha añadido la última de la lista, si volvéis a poner el Precio en el formulario, tendrá prioridad el que haya entrado el usuario (ya que la factoría que crea el value provider con los datos POST está antes de nuestra factoría).

Os dejo un proyecto de demo. La vista inicial muestra tres enlaces: Formulario con los tres campos, formulario con dos campos pero precio en la url y formulario con dos campos. Al hacer submit del formulario se nos muestran los detalles del producto entrado. Veréis como en el último caso (formulario con dos campos) aparece el valor de precio 999 que es el que se ha sacado del web.config (en el primer caso tiene preferencia el valor entrado por el usuario y en el segundo el valor de la url).

Os podeis descargar el proyecto desde aquí (enlace a mi skydrive).

Espero que te haya quedado más o menos clara la idea de los value providers… en un post próximo hablaré de los ModelBinders para que podamos tener la foto completa!

Saludos!

12 comentarios sobre “ASP.NET MVC: ValueProviders”

  1. Magnificos post de mvc me han servido bastante.

    Y pues tengo una duda acerca de esto 🙂

    Dado que no siempre requerire que haga el binding con una cookie( o alguno otro ) en alguna peticion; siempre se crearan los valueProviders no??

    no hay una forma de decirle cuando necesito que si lo haga y cuando no??, digo para que se crean cosas que no las ocupare

  2. @Dámaso
    Pues hasta donde yo sé, no hay manera de evitar que se creen alguno de los ValueProviders. De todos modos, son objetos de ciclo de vida cortos (una petición) y debemos confiar en que el Garbage Collector hará bien su trabajo.

    Es importante tener en cuenta que POR CADA PETICIÓN se crean los ValueProviders, por lo tanto debemos evitar que su construcción sea costosa.

    Un saludo y muchas gracias por tu comentario!!! 😉

  3. muchas gracias por el post. Te hago una consulta, para asp.net mvc que opcion recomendarias para el sigiuente escenario:

    – lista de productos con filtros para manipulacion de datos.

    – el usuario puede filtrar mediante multiples opciones.

    – las opciones seleccionadas por el usuario en cada seleccion se mantienen para la siguiente pagina agregando la ultima seleccion a las variables pasadas.

    Ejemplo en el caso descripto en este ejemplo tendrias:
    paso 1 lista de productos con filtro ?Precio=100
    paso 2 lista de productos donde el usuario selecciona ademas pais ?Precio=100&Pais=es
    paso 3 nuevamente elige otra opcion ejemplo ciudad
    ?Precio=100&Pais=es&Ciudad=bar

    muchas gracias,

    sebastian

  4. Buenas!
    Si pasas los datos via querystring, para «bindearlos» al controlador no necesitas hacer nada. ASP.NET MVC ya trae un value provider de serie para querystring, así que en tu caso te basta cn que la acción tenga un parámetro Precio, otro País y otro Ciudad.
    O todavía mejor una clase tipo:
    public class Data
    {
    string Precio {get; set;}
    string Pais {get; set;}
    string Ciudad {get; set;}
    }

    Y que la acción tenga como parámetro un objeto Data.

    Por otra parte, si NO quieres usar querystring (a mi es que no me gusta nada ver un ?) y los parámetros son siempre en el mismo orden (precio, pais y ciudad) puedes añadir una ruta que te mapee esos tres parámetros. Es decir tener URLs de la forma:
    /controlador/accion/100/es/bar
    donde Precio = 100, es = Pais y Ciudad = bar
    En este caso el controlador sigue teniendo un parámetro de tipo Data pero debes añadir la ruta, algo como (lo pongo de memoria):

    routes.MapRoute(«xxx»,
    «Foo/{action}/{Precio}/{Pais}/{Ciudad}»,
    new { controller=»xxx», action=»Index», Precio=UrlParameter.Optional, Pais=UrlParameter.Optional, Ciudad=UrlParameter.Optional });

    En este caso mapeo las URLs que empiezen por /Foo. Eso, ya dependería de cada caso…

    Finalmente, si los parámetros pueden ir en cualquier orden (o los hay que pueden aparecer o no) a lo mejor te sirve lo que publiqué en http://geeks.ms/blogs/etomas/archive/2011/04/03/asp-net-mvc-pasar-par-225-metros-a-trav-233-s-del-pathinfo.aspx

    Un saludo!

  5. Hola Eduard, muchas gracias por la respuesta y realmente genial el blog. hace rato que estoy leyendo los posts y uno es mas genial que el otro, realmente muy bueno!.

    Actualmente estoy usando querystrings – no conocia la implementacion tan directa por rutas y la voy a probar- , sobre querystrings lo que me pasa es que estoy precisando conocer cual es el mejor metodo para persistir las anteriores opciones que se fueron seleccionando.

    mi idea es listar los resultados ofreciendo un form en el sidebar para que filtre los resultados. No se si usar un cookie, si usar tempdata o que para mantener las anteriores selecciones cuando el usuario manipula – filtra -un resultado de datos en varios pasos. Un ejemplo es la web de mundoanuncio.com cuando lista una categoria:
    http://www.mundoanuncio.com/nf/Listing/navigatorSearch?2=29&categoryId=3&locationId=1&45=8477

    muchas gracias por todos los aportes, saludos!

Responder a etomas Cancelar respuesta

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