burbujas en .NET

C# Básico: Objetos y referencias

2011-08-10T18:25:00.001+02:00

La verdad es que ahora hacía bastantes meses que no publicaba nada de la serie “C# básico”. En esta serie pongo posts sobre temas básicos del lenguaje. No es un libro por fascículos, ni un tutorial al uso puesto que los posts no tienen orden en concreto y nacen a partir de inquietudes que observo (mayoritariamente en los foros, pero también por correos que recibo). Todos los posts de esta serie los podéis ver aquí.

En el post de hoy quiero hablar de la diferencia entre objetos y referencias ya que observo que no siempre está clara. Gente que entiende los conceptos básicos de herencia parece liarse en este punto. Muchas veces es un tema pasado rápidamente en muchos libros y tutoriales. Y es que, la verdad, es un tema muy sencillo… ;-)

MiClase miObjeto = new MiClase();

¿Qué hace este código? En muchos sitios leerás que lo que hace es crear un objeto de la clase MiClase. Eso es cierto, pero describe lo que hace lo que hay a la derecha del símbolo de asignación. Qué hace el código que está a la izquierda? Pues lo que hace es declarar una referencia de tipo MiClase. Otra palabra que se usa muchas veces en lugar de referencia es variable aunque no son técnicamente lo mismo (hay variables que no son referencias y las referencias pueden asignarse a otros elementos que no llamamos usualmente variables como p.ej. los parámetros a una función).

Las referencias contienen objetos. Yo prefiero decir que las referencias apuntan a objetos (aunque esta palabra parece como “maldita”, sin duda por culpa de los punteros) para que quede claro que un mismo objeto puede estar contenido en (apuntado por) más de una referencia.

El tipo de una referencia

Todas las refencias tienen un tipo. Este tipo es único e inmutable durante toda la vida de la referencia. El tipo de una referencia determina que objetos puede contener dicha referencia. En concreto:

Objetos del mismo tipo. Es decir, una referencia de tipo MiClase puede contener objetos de la clase MiClase.

Objetos de una clase derivada de la clase del tipo de la referencia. Si la referencia es de tipo MiClase puede contener objetos de cualquier clase derivada de MiClase.

Objetos de cualquier clase que implemente el tipo de la referencia. Eso aplica sólo si el tipo de la referencia es una interfaz. En este caso la referencia puede contener un objeto de cualquier clase que implemente dicha interfaz.

Todas las clases en .NET derivan de Object. Por lo tanto, según el punto (2) una referencia de tipo Object, puede contener cualquier objeto de cualquier clase:

Object objeto = new CualquierClase();

¿Condiciona alguna cosa más el tipo de la referencia? Pues sí: el tipo de la referencia condiciona como vemos al objeto contenido en dicha referencia. Es decir, la referencia es como un disfraz para el objeto. Le permite “ocultar su tipo real” y mostrarse como el “tipo de la referencia”.

P.ej. dado el siguiente código:

class MiClase
{
  public void Foo() {}
}

class MiClaseDerivada : MiClase
{
   public void Bar() {}
}

MiClase c1 = new MiClaseDerivada();
MiClaseDerivada c2 = new MiClaseDerivada();

Podemos ver como MiClase define un método (Foo) y MiClaseDerivada que deriva de MiClase añade el método Bar. Luego c1 es una referencia de tipo MiClase que contiene un objeto de MiClaseDerivada (puede según el punto 2 anterior). Y c2 es una referencia de tipo MiClaseDerivada que contiene un objeto de MiClaseDerivada (posible según el punto 1 anterior). Entonces tenemos que:

c1.Foo();   // Ok.
c1.Bar();   // No compila.
c2.Foo();   // Ok.
c2.Bar();   // Ok.

La llamada c1.Bar() no compila. ¿Por que? Pues simplemente porque la referencia es de tipo MiClase. Y MiClase no tiene ningún método Bar. Da igual que el objeto contenido por dicha referencia sea de tipo MiClaseDerivada, que sí que tiene el método Bar. El compilador no se fija en los tipos de los objetos. Se fija en los tipos de las referencias.

Objetos compartidos

Como hemos dicho antes un mismo objeto puede estar contenido por más de una referencia:

MiClaseDerivada c1 = new MiClaseDerivada();
MiClase c2 = c1;

En este punto tenemos dos referencias. Pero un sólo objeto. Es decir, c1 y c2 contienen el mismo objeto, que es un objeto de tipo MiClaseDerivada. Si accedo al objeto a través de c1 lo veo como un objeto de tipo MiClaseDerivada (ya que este es el tipo de c1). Por otro lado si accedo al objeto a través de c2 lo veo como un objeto de tipo MiClase (al ser este el tipo de c2). Por lo tanto c1.Bar() es correcto y c2.Bar() no compila.

Pero insisto: son el mismo objeto. Observad el siguiente código:

class Program
 {
     public static void Main()
     {
         MiClaseDerivada c1 = new MiClaseDerivada();
         MiClase c2 = c1;
         c1.Incrementar();
         c2.Incrementar();
         Console.WriteLine("El valor de c1 es:" + c1.Valor);
         Console.WriteLine("El valor de c2 es:" + c2.Valor);
     }
 }


 class MiClase
 {
     private int valor;

     public int Valor { get { return this.valor; } }
     public void Incrementar()
     {
         valor++;
     }
 }

 class  MiClaseDerivada : MiClase
 {
     // Código
 }

¿Cual es la salida por pantalla de dicho código? Pensadlo con detenimiento. Pues la siguiente:

El valor de c1 es:2

El valor de c2 es:2

Eso es debido porque c1 y c2 contienen el mismo objeto. Por lo tanto inicialmente tenemos que el valor de dicho objeto es 0. Al llamar a c1.Incrementar() el valor pasa a ser 1. Y al llamar a c2.Incrementar(), el valor pasa a ser 2, ya que el objeto que contiene c2 es el mismo que el objeto que contiene c1.

Así pues recordadlo siempre: Asignar una referencia a otra NO crea un nuevo objeto. Simplemente hace que la referencia contenida a la izquierda de la asignación contenga EL MISMO objeto que la referencia situada a la derecha.

Comparando objetos y referencias.

De nuevo la forma más fácil es verlo con un código de ejemplo:

class Program
{
    public static void Main()
    {
        Persona p1 = new Persona();
        p1.Nombre = "Pepito";
        p1.Edad = 20;
        Persona p2 = p1;
        Persona p3 = new Persona();
        p3.Nombre = "Pepito";
        p3.Edad = 20;
        bool b = p2 == p1;
        bool b2 = p3 == p2;
    }
}

class Persona
{
    public string Nombre { get; set; }
    public int Edad { get; set; }
}

¿Cual es el valor de b y b2?

b vale true porque p1 y p2 contienen el mismo objeto

b2 vale false porque p3 y p2 contienen objetos distintos. Da igual que los dos objetos sean del mismo tipo y sean idénticos. En este caso son dos Personas idénticas: mismo nombre y edad. Pero el operador == compara referencias, no objetos.

Así pues recuerda: El operador == al comparar referencias devuelve true sólo si las dos referencias contienen el mismo objeto. En caso contrario devuelve false (aunque las dos referencias apunten a dos objetos idénticos).

Nota: Este comportamiento del operador == puede modificarse para que compare el valor de los objetos en lugar de indicar si las dos referencias contienen el mismo objeto. P.ej. la clase string tienen modificado dicho operador para comparar el valor de las cadenas. Esto queda fuera del alcance de este post.

La comparación de objetos (es decir, determinar si dos objetos son idénticos pese a ser dos objetos distintos) es algo que por norma general depende de la clase. P.ej. dos Personas serán iguales si tienen el mismo nombre y edad. Dos cadenas serán iguales si contienen los mismos carácteres. Depende de cada clase determinar que significa que dos objetos son iguales. Para estandarizar un poco la comparación de objetos, en .NET tenemos el método Equals. Dicho método está definido en la clase Object y por lo tanto, por herencia, existe en todas las clases. Si quiero indicarle al framework como comparar dos objetos de tipo Persona puedo añadir a la clase Persona el siguiente código:

public override bool Equals(object obj)
{
    if (obj is Persona)
    {
        Persona otro = (Persona) obj;
        return otro.Edad == Edad &&
               otro.Nombre == Nombre;
    }
    return false;
}

Y para comparar los objetos, debo llamar a Equals en lugar del operador ==

bool b2 = p3.Equals(p2);

Conversiones (castings)

En el código del método Equals anterior hay el siguiente código:

Persona otro = (Persona)obj;

El código (Persona) es lo que se llama casting. El casting lo que hace es cambiar el tipo de una referencia. Es decir en el caso anterior obj era una referencia de tipo object (los parámetros también pueden ser referencias). Recordad que las referencias de tipo object pueden contener cualquier objeto. Pero yo quiero acceder a Nombre y Edad que son campos definidos en la clase Persona y por ello necesito una referencia de tipo Persona que me contenga el mismo objeto que la referencia obj.

Si directamente probáramos:

Persona otro = obj;

Dicho código no compila. ¿Porque? Pues porque otro es una referencia de tipo Persona y por lo tanto solo puede contener:

Un objeto de tipo Persona

Un objeto de cualquier clase que derive de Persona

Pero obj es una referencia de tipo object y puede contener un objeto de tipo object o bien un objeto de cualquier clase que derive de object… es decir, de cualquier clase. Imaginad, entonces:

object obj = new Perro();
Persona otro = obj;

Es evidente que el objeto contenido por obj es un perro y no una persona. Si el código de la segunda línea compilase estaríamos viendo un perro como una persona y bueno… se supone que no se puede, no? Por eso, como el compilador no puede garantizar que el objeto (recordad que el compilador no se fija en objetos) contenido por la referencia obj sea de un tipo válido para la referencia otro, se cura en salud y no nos deja compilar el código.

Pero… tu no eres el compilador y tu sí te fijas en los objetos. ¿Qué pasa en aquellos casos en que tu sabes que el objeto contenido por la referencia obj es de un tipo válido para la referencia Persona? Pues que debes decírselo al compilador. ¿Cómo? Usando el casting:

Persona otro = (Persona)obj;

Aquí le estás diciendo al compilador: Quiero que la referencia otro contenga el mismo objeto que la referencia obj y tranquilo, no te quejes porque yo te digo que el objeto es de tipo Persona. Con el casting el compilador te cree y te deja hacer la asignación.

Eh… que te crea el compilador no significa que te crea el CLR. El CLR no se fía ni de su madre, así que si tu haces:

object perro = new Perro();
Persona persona = (Persona)perro;

El compilador no se quejará, pero cuando ejecutes, vas a recibir una hermosa InvalidCastException. El CLR sí que se fija en los objetos, como tu :)

Ah! Y aunque el compilador no se fije en objetos… no lo insultes, eh? No intentes algo como:

Perro perro = new Perro();
Persona persona = (Persona)perro;

Eso no compila. La razón es porque no es necesario fijarse en los objetos para ver que una referencia de tipo Persona nunca podrá contener el mismo objeto que una referencia de tipo Perro: Persona y Perro no tienen nada en común. El compilador puede no fijarse en los objetos, pero no es tonto!

Un saludo!

[Webcast–AUGES] Introducción a ASP.NET MVC

2011-05-11T22:28:00.001+02:00

Seguramente la mayoría ya sabréis que gracias al empuje del maestro Luis Ruiz Pavón (que nos ha ido convenciendo a varios), se ha creado AUGES, el grupo de usuarios de ASP.NET de España.

Para mi es un honor y un placer poder formar parte de este grupo, pero todavía es un placer más grande inaugurar la agenda de eventos del grupo. Y como no podía ser de otro modo el evento será un Webcast de ASP.NET MVC. :)

La fecha? El Miércoles 18. La hora? A las 19:30 (hora española peninsular).

La idea es hacer un evento 100% introductorio: explicar que es esto de ASP.NET MVC, ver ejemplos y comentar cosillas básicas. Más adelante ya tendremos tiempo de hacer eventos más hardcore sobre el tema! ;-)

Así que, ya sabes… si has oído a hablar de MVC y quieres ver de que se trata, o si conoces implementaciones de MVC en otros sistemas y quieres ver la de Microsoft, o si simplmente quieres escucharme un rato (mmmm…. :p) pásate por la web de registro y… nos conectamos el miércoles!!

Saludos… y nos vemos! ;-)

PD: Como siempre… crosspost desde mi blog de geeks.ms

[ASP.NET MVC] Pasar parámetros a través del PathInfo

2011-04-03T21:09:00.001+02:00

¡Muy buenas! Bueno, el título del post no queda demasiado claro, pero a ver si consigo explicar un poco la idea. ;-)

Los que habéis usado ASP.NET MVC estáis muy acostumbradas a las URLs del estilo /controlador/accion/id, es decir algo como:

/Home/Index/10
/Articles/View/Eiximenis
/Blog/View/10293

Sabemos que gracias a la tabla de rutas podemos pasar tantos parámetros como queramos, y así podríamos tener URLs del tipo:

/Articles/View/Eiximenis/MVC/2011

Que podría devolverme los articulos de “Eiximenis” con el tag “MVC” y del año 2011.

El único punto a tener presente es que el orden de los parámetros importa, es decir no es lo mismo /Articles/View/Eiximenis/MVC/2011 que /Articles/View/2011/MVC/Eiximenis. En el primer caso buscamos los artículos de Eiximenis sobre MVC en el 2011 y en el segundo caso buscaríamos los artículos del blogger 2011, sobre MVC en el año de Eiximenis. Y sin duda Fra Francesc Eiximenis, fue un gran escritor, pero que yo sepa todavía no se le ha dedicado un año (algo totalmente injusto, por supuesto :p).

En este artículo quiero enseñaros una manera para que podáis gestionar URLs del tipo:

/Articles/View/Author/Eiximenis/Tag/MVC/Year/2011
/Articles/View/Tag/MVC/Year/2011/Author/Eiximenis

Y que ambas URLs sean tratadas de forma idéntica. En este caso estaríamos pasando tres parámetros: Author, Tag y Year.

Para conseguir este efecto nos bastan dos acciones muy simples: definir un route handler nuevo y una entrada a la tabla de rutas.

El route handler lo único que debe hacer es recoger la información de la URL y parsearla en “tokens” (usando el ‘/’ como separador). Y por cada par de tokens añadir una entrada en los valores de ruta (route values). El código es muy simple:

public class UrlRouteHandler : MvcRouteHandler
{
    protected override IHttpHandler GetHttpHandler(RequestContext requestContext)
    {
        var path = requestContext.RouteData.Values["pathInfo"];
        if (path != null)
        {
            var tokens = path.ToString().Split('/');
            for (var idx =0; idx<tokens.Length; idx+=2)
            {
                if (idx+1 < tokens.Length)
                {
                    requestContext.RouteData.Values.Add(tokens[idx], tokens[idx+1]);
                }
            }
        }

        return base.GetHttpHandler(requestContext);
    } 
}

Una pequeña nota es que la cadena que separamos en tokens, no es toda la URL sino “pathInfo” un parámetro de ruta que ya nos vendrá dado. Este parámetro de ruta contendrá todo aquello que no es ni el controlador ni la acción. Es decir en la URL /Articles/View/Author/Eiximenis/Tag/MVC/Year/2011 el valor de pathInfo será Author/Eiximenis/Tag/MVC/Year/2011 (que son justo los parámetros).

Ahora nos queda añadir la entrada a la tabla de rutas. En mi ejemplo yo he eliminado la entrada “Default” que genera VS2010 y la he sustituído por:

routes.Add("Default", new Route(url: "{controller}/{action}/{*pathInfo}",
    routeHandler: new UrlRouteHandler(),
    defaults: new RouteValueDictionary(new {controller = "Home", action = "Index"})));

La clave aquí está en el {*pathInfo}. Aquí le digo al sistema de rutas que coja todo lo que venga después de /{controller}/{action} y me lo añada a un parámetro de ruta llamado pathInfo. Además de eso, en esta ruta le indico que su routeHandler será una instancia de la clase UrlRouteHandler que hemos creado antes.

Y listos! Una vez los datos están en el route value ya puede entrar en acción el sistema de binding de ASP.NET MVC lo que quiere decir que puedo crear un controlador como el siguiente:

public class ArticlesController : Controller
{
    public ActionResult View(string author, string tag, int? year)
    {
        dynamic data = new ExpandoObject();
        data.Author = author ?? "Sin formato";
        data.Tag = tag ?? "Sin confirmación";
        data.Year = year.HasValue ? year.ToString() : "Sin año";
        return View(data);
    }
}

Que recibiría los parámetros de las URLs que hemos visto anteriormente.

Un saludo a todos!

PD: De nuevo eso es un crosspost desde mi blog en geeks.ms!

[HTML/JS] Module pattern

2011-03-28T17:33:00.001+02:00

Muy buenas! Cuando creas un sitio web, es normal que vayas añadiendo cada vez más código javascript en él. Al final, seguramente terminaréis desarollando una mini-api, propia que muchas veces reside en un archivo .js, lleno de funciones. Algo como:

function HazAlgo(id, params, callback)
{
}

function _HazAlgoHelper(domObj, params)
{
}

En este caso tenemos dos funciones, HazAlgo y _HazAlgoHelper. La función _HazAlgoHelper es realmente una función privada, es decir está pensada para ser llamada únicamente dentro de HazAlgo. Pero en Javascript no existe directamente el concepto de función privada así que le ponemos un idicador (que empieze por _) y asumimos que todas las funciones que empiecen por _, son privadas.

Como podemos ver, el código javascript no está muy “organizado”: tenemos todas las funciones juntas y además podemos ver aquellas que no deberíamos. El patrón de módulo existe para solventar esos problemas.

El patrón de módulo

La idea del patrón de módulo (module pattern) en Javascript es simular el concepto de una clase estática con métodos públicos y métodos privados. Lo de clase estática viene porque no quiero ir creando objetos de mi módulo, simplemente quiero tener ahí, las funciones públicas. Pero sin ver las privadas. Para los que no lo sepáis: en javascript no existe el concepto de variable estática.

La idea que hay detrás del patrón de módulo es muy simple, y como casi siempre pasa simple significa también brillante: Se trata de crear un objeto anónimo, cuyos campos públicos sean las funciones públicas. Finalmente se crea una instancia de ese objeto y se asigna al namespace global (eso es, al objeto window).

El código de base sería algo como:

(function(wnd) {
    var miModulo = function() {
        var _HazAlgoHelper = function(domObj, params) {alert("método privado");};
        var _HazAlgo = function(id, params, callback) { _HazAlgoHelper(); alert("método público"}; };

        return {
           HazAlgo : _HazAlgo
        };
    }

    wnd.m$ = miModulo();
})(window);

Bien… se que el código puede parecer lioso, la primera vez, pero vamos a analizarlo.

Podemos ver que estamos definiendo una función anónima que acepta un parámetro (llamado wnd).

¿Y que hace esa función anónima)? Pues para empezar define una variable miModulo que resulta ser… una función (var miModulo = funcion() { …}).

Y que hará esa función cuando se invoque? Pues tres cosas:

Definir una variable llamada _HazAlgoHelper… que es otra función.

Definir una variable llamada _HazAlgo… que es otra función.

Devolver un objeto anónimo con un campo, llamado HazAlgo. El valor de HazAlgo es el mismo que _HazAlgo (es decir una función).

Con eso tenemos una función (miModulo) que cuando la invoquemos nos devolverá un objeto con un solo campo (llamado HazAlgo). Así, teoricamente:

miModulo.HazAlgo();    // Valido
miModulo._HazAlgo();   // No válido
miModulo._HazAlgoHelper(); // NO válido

Fijaos que la gracia está en que HazAlgo() realmente es lo mismo que _HazAlgo()… y desde _HazAlgo() podemos llamar sin ningún problema a _HazAlgoHelper() que es nuestra función privada. Así la clave es mapear las funciones públicas como campos del objeto anónimo devuelto.

¡Con eso hemos simulado el concepto de funciones privadas!

Pero, miModulo es una variable local, es local a la función anónima que estamos definiendo. Así que todavía nos queda un paso más: Guardar miModulo en alguna propiedad del parámetro wnd. Eso es lo que hacemos con la línea:

wnd.m$ = miModulo();

Invocamos miModulo (con parentesis, pues es una función) y guardamos el resultado (el objeto anónimo con el campo HazAlgo) en la propiedad m$ del parámetro wnd.

Ya casi estamos… Hasta este punto hemos definido simplemente una función anónima. Ahora toca invocarla. Fijaos en un detalle importante: la primera línea empieza con un paréntesis abierto. Con eso, de hecho, estamos invocando nuestra función anónima. Pero nuestra función anónima espera un parámetro (wnd) así que debemos pasárselo. Eso es lo que hacemos en la última línea: le pasamos window. Y porque window? Pues porque window es un namespace global: todo lo que esté en window es global.

Por lo tanto ahora, desde cualquier parte de mi página puedo hacer:

<script>m$.HazAlgo(1,2,3);</script>

Y eso es correcto, mientras que hacer.

<script>m$._HazAlgoHelper(1,2);</script>

Nos dará un error.

Para tener nuestro módulo listo para ser usado, basta con tenerlo en un .js propio e incluirlo en aquellas páginas donde lo necesitemos. ¡Y listos!

Espero que esto os parezca interesante y os ayude a organizar vuestro código javascript!

Un saludo!

PD: Como siempre… un crosspost desde mi blog en geeks.ms!

ASP.NET MVC: Previsualizar imágenes subidas (2)

2011-03-15T14:56:00.001+01:00

Buenas! Donde dije digo, digo Diego… Sí, ya sé que dije que el segundo post sería como hacerlo con Ajax, pero bueno… la culpa es de twitter, concretamente de @pablonete con el que hemos empezado a hablar sobre si es posible evitar el guardar la imágen físicamente en el servidor. Hay un mecanismo obvio, que es usar la sesión (guardar el array de bytes que conforman la imágen en la sesión). Pero… hay otra? Pues sí: usar data urls!

Data urls

Lo que mucha gente no conoce es que el formato de URL permite incrustar datos que son interpretados por el navegador como si se los hubiese descargado externamente. P.ej. la siguiente url es válida:

data:image/jpeg;base64,xxxxxxx

donde xxxxxxx es la codificación en base64 de la imágen.

P.ej. eso es totalmente correcto:

<img src=”data:image/jpeg;base64,xxxxxx” />

Veamos como podríamos modificar nuestro proyecto anterior, para usar data urls en lugar de un fichero temporal en el servidor… Fijaos que eso sólo evita guardar el fichero, la imagen debe ser subida al servidor.

Las modificaciones son muy simples, por un lado primero vamos a modificar la acción del controlador, para que quede así:

[HttpPost]
public ActionResult SendImage(HttpPostedFileBase img, string base64, string contenttype)
{
    if (base64 != null && contenttype != null && img==null)
    {
        // Aquí podríamos guardar la imagen (en base64 tenemos los datos)
        return View("Step2");
    }
    var data = new byte[img.ContentLength];
    img.InputStream.Read(data, 0, img.ContentLength);
    var base64Data = Convert.ToBase64String(data);
    ViewBag.ImageData = base64Data;
    ViewBag.ImageContentType = img.ContentType;
    return View("Index");
}

La acción recibe tres parámetros:

img: El fichero seleccionado (contenido del <input type=”file”).

base64: Codificación en base64 de la imagen que se está previsualizándo.

contenttype: Content-type de la imagen que se está previsualizando.

Por supuesto base64 y contenttype sólo se envían si se está previsualizando una imagen. En caso contrario valen null.

Fijémonos lo que hace la acción, si base64 y contenttype valen null, o bien el usuario ha seleccionado una imagen nueva (img != null):

Obtenemos los datos en base64 de la imagen enviada por el usuario (base64Data).

Pasamos esos datos (junto con el content-type) a la vista, usando el ViewBag.

Y la vista que hace? Pues poca cosa:

<form enctype="multipart/form-data" method="post" action="@Url.Action("SendImage")">
    <label for="img">Seleccionar imagen:</label>
    <input type="file" name="img" /> <br />
    <input type="submit" />

    @if (ViewBag.ImageData != null)
    {   
        <img src="data:@ViewBag.ImageContentType;base64,@ViewBag.ImageData" />
        <input type="hidden" value="@ViewBag.ImageData" name="base64" />
        <input type="hidden" value="@ViewBag.ImageContentType" name="contenttype" />
    }
</form>

Tenemos el formulario con el input type=”submit”, y luego si en el ViewBag vienen los datos de la imagen que se debe previsualizar, genera 3 campos más:

Una imagen, cuyo src es una data url (formato data:content-type;base64,[datos en base64])

Dos campos hidden (para guardar el content-type y los datos para mandarlos de vuelta al servidor).

Y listos! Con eso tenemos la previsualización de las imágenes sin necesidad de generar fichero temporal alguno.

Finalmente, tres aclaraciones:

Fijaos que la codificación en base64 se incrusta en la página (en este caso se incrusta dos veces, aunque con un poco de javascript podría incrustarse solo una), por lo que esto puede generar páginas muy grandes si la imagen ocupa mucho.

Si no voy errado, los navegadores sólo están obligados a soportar URLs de hasta 1024 bytes. Todo lo que exceda de aquí… depende del navegador. Firefox p.ej. acepta URLs muy largas, pero recordad que Base64 genera fácilmente URLs no muy largas, sinó descomunalmente largas (si la imágen ocupa 100Ks, la URL en Base64 ocupará más de 100Ks). Así que para imágenes pequeñas igual tiene sentido, pero para imágenes largas, honestamente no creo que sea una buena solución.

La mayoría de navegadores modernos soportan data urls (IE lo empezó a hacer con su versión 8).

En fin… bueno, como curiosidad no está mal, eh? ;-)

Gracias a Pablo Nuñez por la divertida e interesante conversación en twitter!

Saludos!

PD: Enlace al post anterior de esa serie: http://geeks.ms/blogs/etomas/archive/2011/03/15/asp-net-mvc-previsualizar-im-225-genes-subidas-1.aspx

PD2: Otro crosspost des de mi blog en geeks.ms…

ASP.NET MVC: Previsualizar imágenes subidas (1)

2011-03-15T10:01:00.001+01:00

Buenas! Una pregunta que últimamente parece que se pregunta varias veces en los foros de ASP.NET MVC es como previsualizar una imagen que se quiere subir al servidor.

Antes que nada aclarar que, técnicamente, la pregunta está mal hecha: no es posible previsualizar la imagen antes de que sea subida. Antiguamente en algunos navegadores, y con un poco de javascript, eso era posible, pero ahora por suerte eso ya no funciona :)

Básicamente previsualizar una imagen consiste en:

Recibir los datos de la imagen
Guardarla en algún sitio “temporal”
Mandarla de vuelta al navegador
Borrar la imagen del sitio “temporal” si el usuario no la acepta

En este primer post vamos a ver como hacerlo sin usar Ajax. Luego habrá un segundo post y veremos como hacerlo usando Ajax (no es tan sencillo porque XMLHttpRequest no soporta el formato de datos multipart/form-data que es el que se usa cuando se mandan ficheros).

Bien, vamos a verlo rápidamente, ya veréis cuan sencillo es :)

Lo primero es tener la vista que tenga el formulario para enviar los datos. La siguiente servirá (si queréis más detalles de como hacer upload de ficheros en MVC mirad mi post al respecto):

<h2>Index</h2>

<form enctype="multipart/form-data" method="post" action="@Url.Action("SendImage")">
    <label for="img">Seleccionar imagen:</label>
    <input type="file" name="img" /> <br />
    <input type="submit" />
</form>

Trivial: un form con multipart/form-data que enviará sus datos a la acción SendImage. La acción podría ser algo como:

[HttpPost]
public ActionResult SendImage(HttpPostedFileBase img)
{
    var data = new byte[img.ContentLength];
    img.InputStream.Read(data, 0, img.ContentLength);
    var path = ControllerContext.HttpContext.Server.MapPath("/");
    var filename = Path.Combine(path, Path.GetFileName(img.FileName));
    System.IO.File.WriteAllBytes(Path.Combine(path, filename), data);
    ViewBag.ImageUploaded = filename;
    return View("Index");
}

Vale, fijaos que recibimos el HttpPostedFileBase (llamado img como el atributo name del input type=”file”). Lo que hacemos en la acción es muy simple:

Guardamos la imagen en disco (en este caso por pura pereza uso el directorio raíz de la aplicación web. Por supuesto lo suyo es usar un directorio configurado en web.config y con los permisos NTFS correspondientes).

Coloco en el ViewBag el nombre de la imagen que se ha guardado (luego vemos porque).

Devuelvo la vista “Index” (la misma de la cual venimos)

Ok, tal y como lo tenemos ahora, si lo probáis veréis que podéis hacer un upload de la imagen, y la imagen se graba en el disco (en el directorio raíz de la aplicación web), pero no se previsualiza nada. Vamos a modificar la vista Index para que haya esa previsualización.

Para previsualizar la imagen basta con añadir el siguiente código, despues del </form> en la vista:

@if (!string.IsNullOrEmpty(ViewBag.ImageUploaded))
{
    <img src="@Url.Action("Preview", new {file=ViewBag.ImageUploaded})" />
}

Simple, no? Si en el ViewBag existe la entrada ImageUploaded generamos un tag <img> cuya dirección es la acción “Preview” y le pasamos el parámetro file con el nombre de la imagen. Y como es la acción Preview? Pues super sencilla:

public ActionResult Preview(string file)
{
    var path = ControllerContext.HttpContext.Server.MapPath("/");
    if (System.IO.File.Exists(Path.Combine(path, file)))
    {
        return File(Path.Combine(path, file), "image/jpeg");
    }
    return new HttpNotFoundResult();
}

Simplemente leemos la imagen guardada y la devolvemos usando un FilePathResult. Simple, eh? ;-)

Con eso, si subís una imagen, cuando le deis a submit, aparecerá de nuevo la vista, pero ahora previsualizando la imagen.

Ahora sólo nos queda el punto final: Que el usuario pueda aceptar esa imagen como correcta. Para ello lo más simple es hacer lo siguiente:

Si el usuario está previsualizando una imagen y NO ha seleccionado otra, cuando hace el submit se entiende que acepta dicha imagen.

Si el usuario NO está previsualizando una imagen, o bien está previsualizando una pero selecciona otra, al hacer el submit se entiende que descarta la imagen anterior y quiere previsualizar la nueva.

Para ello, tenemos que hacer que la vista le indique al controlador si se está previsualizando una imagen, y cual és. Por suerte eso es muy sencillo. Basta con modificar el <form> de la vista para que su atributo action quede como:

<form enctype="multipart/form-data" method="post" 
action="@Url.Action("SendImage", new {previewed=ViewBag.ImageUploaded})">

Fijaos que añadimos un parámetro previewed que la vista mandará a la acción y que será el nombre de la imagen que se está previsualizando.

Vamos a modificar la acción para que reciba ese parámetro y actúe en consecuencia:

[HttpPost]
public ActionResult SendImage(HttpPostedFileBase img, string previewed)
{
    if (!string.IsNullOrEmpty(previewed) && img == null)
    {
        ViewBag.ImageName = previewed;
        return View("Step2");
    }

    // Código tal cual estaba
}

Añadimos ese if al inicio: Si el usuario está previsualizando una imagen y no ha seleccionado otra, entendemos que acepta esta imagen. Entonces guardamos el nombre en el ViewBag y lo mandamos a la siguiente vista (Step2).

La vista es muy sencilla:

<h2>Step2</h2>

Siguiente paso. El usuario ha aceptado la imagen: <br />

<img src="@Url.Action("Preview", new {file=ViewBag.ImageName})" />

Simplemente mostramos la imagen. Fijaos que de nuevo usamos la acción Preview, puesto que la imagen ya la tenemos guardada en el servidor.

Notas finales

Faltarían, al menos, dos cosas para que dicho proyecto funcionase “de forma aceptable”:

Borrar las imagenes descartadas por el usuario (en la acción SendImage si se recibe una imagen nueva y se estaba previsualizando una, borrar esta ya que el usuario la ha descartado).

La acción Preview siempre devuelve content-type a image/jpeg, eso debería hacerse según la extensión de la imagen, o guardarlo en algún sitio.

Ambas cosas son triviales y no las añado porque lo único que consiguiría es liar el código un poco más ;-)

En el próximo post… lo mismo pero usando Ajax.

Saludos!

PD: Pues sí… otro crosspost de mi blog de geeks.ms! Que raro, no? :P

Rendering de vistas parciales en Razor y MVC3

2011-02-25T08:55:00.001+01:00

Buenas! Una de las dudas que he visto que se van repitiendo por ahí tiene que ver con como renderizar vistas parciales en MVC3 usando Razor.

En MVC2 y anteriores (o en MVC3 usando el ViewEngine de WebForms) la forma de renderizar una vista parcial era sencilla:

<% Html.RenderPartial("VistaParcial", modelo); %>

Mucha gente traduce eso a Razor y usa lo siguiente para renderizar una vista parcial:

@Html.RenderPartial("VistaParcial")

Y se obtiene un error, quizá un poco críptico, que dice lo siguiente: CS1502: The best overloaded method match for 'System.Web.WebPages.WebPageExecutingBase.Write(System.Web.WebPages.HelperResult)' has some invalid arguments

El error no está en que Html.RenderPartial no pueda usarse con Razor, el error está en la sintaxis que estamos usando. Cuando en Razor usamos la @ para indicar el inicio de código de servidor, la expresión que viene a continuación debe devolver un valor, que será incluído en la respuesta a enviar al navegador. La excepción a esa norma es cuando lo que sigue a la @ es una palabra clave reservada de Razor (como @model) o una palabra clave reservada del lenguaje que estemos usando (como @foreach). Esos casos especiales Razor los sabe tratar y actúa en consecuencia. Pero en el resto de casos siempre, siempre, siempre la expresión debe devolver un valor.

Hablando en términos del engine de WebForms, el código Razor:

@Html.RenderPartial("VistaParcial", modelo)

Se corresponde a:

<%: Html.RenderPartial("VistaParcial",modelo) %>

Que es erróneo (y da el error CS1502: The best overloaded method match for 'System.Web.HttpUtility.HtmlEncode(string)' has some invalid arguments).

Entonces… como usar Html.RenderPartial en Razor? Fácil: usando llaves para indicarle al motor de Razor que eso es un código que debe ejecutar, en lugar de un valor que debe incrustar en la respuesta:

@{ Html.RenderPartial("VistaParcial"); }

Así pues: Html.RenderPartial puede usarse en Razor sin ningún problema… como el resto de Helpers que conozcáis. Si el método lo usábais con <% … %> en Razor es @{ … }, mientras que si usábais <%: … %> en Razor es simplemente @…

Otras maneras de incrustar vistas parciales

De todas formas hay un par de métodos más para incrustar vistas parciales.

El primer método es Html.Partial() un método de extensión adicional. Para llamarlo se usan los mismos parámetros que Html.RenderPartial. La diferencia es que Html.Partial devuelve una IHtmlString con los contenidos de la vista renderizada. Por lo tanto, para incrustar una vista usando Html.Partial() usamos:

// Razor
@Html.Partial("VistaParcial")
// Webforms viewengine
<%: Html.Partial("VistaParcial") %>

El segundo método es propio de Razor, ya que está definido dentro del framework que se conoce como “WebPages” y es usar el método RenderPage, definido en la clase WebPageBase de la cual heredan las vistas Razor.

Dicho método acepta dos parámetros:

La localización de la vista. Ojo! No el nombre, sinó su localización (incluyendo directorios)

Parámetros a pasar a la vista (params object[]).

P.ej. para renderizar la vista parcial usaríamos:

@RenderPage("~/Views/Home/VistaParcial.cshtml")

Fijaos en que se debe usar el nombre del archivo de la vista a incluir (incluyendo extensión .cshtml).

Si se pasan parámetros a la vista parcial, estos no están disponibles usando la propiedad Model en la vista, sinó que debe usarse la propiedad PageData. P.ej. podríamos pasar una cadena y un entero a la vista:

@RenderPage("~/Views/Home/VistaParcial.cshtml", "Parametro 1", 10)

Y mostrarlos desde la vista con el uso de PageData:

@foreach (var item in PageData)
{
    <div>@item.Value</div>
}

Mi opinión sobre el método RenderPage (en MVC): Sobra totalmente, y espero que nunca, nunca, nunca lo uséis. Porque? Pues porque RenderPage rompe la encapsulación del framework (en lugar de especificar un nombre de vista debéis especificar un fichero). Es evidente que existe para dar soporte a WebPages pero WebPages y MVC se parecen sólo porque usan Razor como sintaxis, pero en concepción son dos cosas totalmente distintas… Aunque por razones (supongo que técnicas) Razor depende de WebPages y esa dependencia se arrastra a MVC3, cosa que personalmente no me gusta demasiado. Pero es lo hay… ;-)

Conclusiones

Html.RenderPartial funciona correctamente en Razor, al igual que el resto de métodos de siempre. Sólo debemos tener cuidado en usar la sintaxis correcta.

Html.Partial es un método adicional para renderizar vistas parciales. La diferencia con Html.RenderPartial() es que este último escribe en la response directamente el contenido de la vista, mientras que Partial() lo devuelve dentro de una cadena. No tengo claras las implicaciones de rendimiento que puede tener empezar a crear mutltiud de cadenas que serán eliminadas por el GC casi de inmediato.

RenderPage es el método de WebPages para renderizar vistas parciales. Desde el punto de vista de MVC es un método que sobra totalmente y que rompe la encapsulación del framework.

Espero que os sea útil!

Un saludo!

De los requerimientos…

2011-02-17T20:38:00.001+01:00

Mi hermano y yo ambos somos arquitectos. Aunque en su caso él tiene un título universitario que lo acredita como tal y yo sólo una tarjeta de trabajo donde mi empresa ha decidido poner eso… y en inglés que se supone que queda mejor. Los dos nos dedicamos a pensar y diseñar cosas: él piensa y diseña espacios habitables (o sea pisos y casas) y yo pienso y diseño soluciones informáticas (o sea programas).

Ayer mi hermano (que no sólo es arquitecto, sinó que regenta una empresa de obras) me vino riéndose por una petición de presupuesto en broma que había recibido. El correo electrónico decía, más o menos, así…

Apreciado hermano de eiximenis,

Nos dirigimos a Ud. para que nos haga un presupuesto para la construcción de una nueva mansión para un concejal cualquiera (a partir de ahora “el cliente”) que, con un golpe de fortuna, ha ganado unos dinerillos que gastar. A continuación le detallamos como debe la mansión:

La mansión contará con el número de habitaciones que el cliente estime cómo necesarias para el desarrollo de sus funciones de descanso y/o copulación. Además el cliente debe poder realizar otras funciones (a especificar en algún momento del futuro) sin menoscabo de la comodidad mínima exigida.
Los materiales de construcción deben tener el nivel de calidad requerido por el cliente, nivel que por supuesto no aparece en ningún estándard y que sólo el cliente conoce y que puede variar en función de su estado de ánimo.
Deberán integrarse, adaptarse o construirse distintos módulos de diversión, para aquellas actividades de ocio que el cliente considere necesarias. No es necesario especificar que las necesidades de ocio del cliente pueden variar en cualquier momento durante el periodo de tres años que se exige como mantenimiento.
El número de baños deberá ser el justo y necesario para que pueda usarlos el cliente, así como los invitados a sus fiestas. El número de invitados no ha sido proporcionado por el cliente.
Se valorará positivamente que los garajes estén listos al cabo de dos semanas y más positivamente si lo están al cabo de una.
El cliente ha comprado un módulo de domótica que deberá ser instalado y configurado. El modelo es desconocido al igual que el fabricante.
Existe un periodo de tres años de garantía, donde el cliente puede solicitar cambios en los materiales, disposición de los módulos, módulos de ocio nuevos, etc, etc

Dado que el cliente es un concejal debe asignar la obra de forma totalmente legal y por ello se deberán entregar tres sobres:

El primero con la propuesta económica final. Dicha propuesta contendrá el precio exacto de la obra, incluyendo materiales y mano de obra y mantenimiento durante los 3 años. El mantenimiento implica adaptar la mansión a las nuevas necesidades que le puedan surgir al cliente. Hay total libertad de precio, siempre que no pase de 500000€
El segundo con el calendario exacto de las obras: cuando estará el garaje, las distintas habitaciones, la fachada principal, los módulos de ocio, etc. El inclumpimiento del calendario acarreará sanciones económicas a determinar.
El tercero con los detalles técnicos, planos de obra, materiales usados, etc

La valoración por concurso será tal y como sigue:

Valoración económica: Un 50% (De 0 a 5 puntos)
Calendario: Un 40% (de 0 a 4 puntos)
Detalles técnicos: Un 10% (de 0 a 1 punto)

Se pide envío de los tres sobres antes de 2 días. El cliente no está disponible para contactar ya que está de vacaciones.

Mi hermano entre carcajadas y carcajada, me insistía en que le viera la gracia a la broma, que si “fíjate que aquí no concretan nada, que si eso es buenísimo porque ni dicen el número de las habitaciones, en que si tal y cual”…

… yo, la verdad es que sonreí un poco por compromiso mientras por dentro pensaba en las muchas veces que mi trabajo parece una broma… y de mal gusto.

Saludos!

[Material] WebCast ASP.NET MVC

2011-02-08T08:53:00.001+01:00

Buenas.

Este post simplemente es para agradeceros a todos el interés que mostrasteis en el Webcast de ASP.NET MVC que tuve el placer de realizar para la gente del Lledia DotNetClub.

Antes que nada os dejo la página desde donde os podéis ver o descargaros el WebCast: https://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?culture=es-ES&EventID=1032476809&CountryCode=ES. En esa página veréis un enlace que pone “Regístrese sin cuenta de Windows Live ID” que es el que os llevará a la página de descarga.

Increíble, eh? Esta vez no la pifié con el livemeeting y quedó grabado! :)

Os dejo:

El código fuente de Porrazo completo. Porrazo, el sistema de porras on-line, fue lo que más o menos fuimos desarrollando a lo largo de los dos webcasts. En el código veréis implementadas todas las técnicas de las que hablamos (con la excepción del helper WebGrid). Por supuesto que Porrazo es un conglomerado de técnicas de hacer las cosas: no significa que todas deban implementarse en una misma aplicación MVC. A vosotros os toca juzgar en cada caso cual es la mejor opción!
Los dos ppts, aunqué no tienen apenas información, ya que son un mero índice.
El script SQL para crear las tablas (sin datos… los datos deberéis ponerlos vosotros… :p).

Lo tenéis en: http://cid-6521c259e9b1bec6.office.live.com/browse.aspx/BurbujasNet/ZipsPosts/Porrazo

En breve me gustaría hacer un documento word (en esa misma carpeta) para que podáis realizar step-by-step Porrazo desde cero y podáis practicar las técnicas que vimos. Pero como ello me va a llevar cierto tiempo, prefiero dejaros los fuentes ya disponibles, y actualizar este post cuando tenga el documento realizado.

Si alquien quiere que le avise personalmente cuando tenga el documento, puede enviarme un mail (mi correo está en los ppts) o contactar conmigo a través del formulario de contacto del blog.

Muchas gracias!

PD: Eso es un crosspost desde mi blog en geeks.ms!

[WebCast] ¿Te quedaste con más ganas? ASP.NET MVC II

2011-02-02T10:20:00.001+01:00

Muy buenas! Este jueves 03 de febrero (o sea mañana) gracias a la gente del Lleida dotnet club, tengo el gusto de dar un WebCast sobre ASP.NET MVC :)

La verdad es que el WebCast está pensado para ser la continuación del que dí el pasado 2 de diciembre. En aquel webcast vimos:

Introducción a ASP.NET MVC
Membership providers para autenticación y autorización
Uso de Unity para desacoplar dependencias
El patrón repositorio para acceder a la BBDD
Uso de Ajax con Json
Templates con jquery-tmpl
Binding de datos en los controladores
Guardando datos en la bbdd: Unit of Work

Todo ello lo vimos desarrollando una aplicación desde cero (al que mi departamento de marketing llamó Porrazo), y este nuevo webcast continuará donde se quedó aquel. Lamentablemente, debido a que soy un negado en eso del livemeeting el webcast no quedó grabado, así que al principio vamos a dar un rápido resumen a lo visto en aquel webcast, para que estemos todos en situación… Y luego proseguiremos con los puntos que se nos quedaron en el tintero:

Uso de un Role Provider
Añadiendo un módulo de administración (áreas)
Componiendo presentación (uso de vistas parciales)
Grids!! (Sí… esa es una feature que la gente pide mucho)
Ventanas flotantes (popups)

Si me da tiempo (espero no volver a enrollarme) veremos algunos temas addicionales como:

Validación de datos en cliente
Unobtrusive javascript

Y al final una sesión de preguntas y respuestas (pero… no os paséis: que sean facilitas, eh? ;-))

Todo ello con ASP.NET MVC3, con VS2010 a tope (nada de power points!) y desarrollando Porrazo, el sistema de porras online que cuando esté finalizado colgaré aquí con la esperanza de que lo compre Google y me retire.

La página de registro esá en: https://msevents.microsoft.com/CUI/Register.aspx?culture=es-ES&EventID=1032476808&CountryCode=ES&IsRedirect=false

Un saludo a todos!

ASP.NET MVC3: Un helper Repeater

2011-01-26T09:37:00.001+01:00

Muy buenas! En el post anterior comenté la característica de los templates de Razor y hoy vamos a ver como podríamos crear un helper que emule un poco el control Repeater que hay en webforms (salvando las distancias, claro).

Vamos a crear un helper externo, es decir que sea reutilizable en distintos proyectos: para ello nuestro helper va a residir en una clase (en mi ejemplo en el propio proyecto web, pero se podría situar en una librería de clases para ser reutilizable).

Esqueleto inicial

A nuestro helper se le pasará lo siguiente:

Una cabecera: template Razor que se renderizará una sola vez al principio.
Un cuerpo: template Razor que se renderizará una vez por cada elemento
Un pie: template Razor que se renderizará una sola vez al final.
Una colección de elementos (por cada elemento se renderizará el cuerpo).

Recordáis que ayer comentamos que los templates Razor son Func<T, HelperResult>?

Bien, pues vamos a declarar nuestro helper:

public static IHtmlString Repeat<TItem>(
    IEnumerable<TItem> items,
    Func<dynamic, HelperResult> header,
    Func<TItem, HelperResult> body,
    Func<dynamic, HelperResult> footer
    )
{
    var builder = new StringBuilder();
    if (header != null)
    {
        builder.Append(header(null).ToHtmlString());
    }
    
    foreach (var item in items)
    {
        builder.Append(body(item).ToHtmlString());
    }
    if (footer != null)
    {
        builder.Append(footer(null).ToHtmlString());
    }

    return MvcHtmlString.Create(builder.ToString());
}

Los templates siempre están declarados como Func<T, HelperResult>, en este caso declaramos tres templates:

header, cuyo parámetro @item es dynamic.

body, cuyo parámetro @item es TItem, donde TItem es el tipo del enumerable que se le pasa al helper

footer, cuyo parámetro @item es dynamic

Para invocar los templates y obtener el html asociado simplemente invocamos el Func (pasándole el parámetro del tipo correcto) y sobre el resultado llamamos a ToHtmlString: Este método nos devuelve la cadena HTML que ha parseado Razor.

Ahora p.ej. me creo una acción tal en el controlador:

public ActionResult List()
{
    return View(new List<Product>
                    {
                        new Product() {Nombre="PS3", Precio=300},
                        new Product() {Nombre="XBox360", Precio=150},
                        new Product() {Nombre="Wii", Precio=100}
                    });
}

Y en la vista asociada:

@using MvcApplication14.Helpers
@model IEnumerable<MvcApplication14.Models.Product>

<table>
@Repeater.Repeat(Model, 
    @<thead><tr><td>Nombre</td><td>Precio</td></tr></thead>, 
    @<tr><td>@item.Nombre</td><td>@item.Precio</td></tr>, 
    null)
</table>

Fijaos en la llamada a Repeater.Repeat, donde le paso el modelo que recibe la vista (que es un IEnumerable de Product) y los tres templates Razor (en este caso no le paso footer y por ello pongo null).

En el segundo template (body) puedo acceder al elemento que se está renderizando mediante @item. Además, dado que en helper he declarado el template body de tipo Func<TItem, HelperResult>, tengo soporte de Intellisense:

Si teclease @item en el template header o footer no tendría intellisense porque los he declarado dynamic en el helper (además ojo, que en el helper le paso null, por lo que rebentaría si usamos @item en el template header o footer).

Y listos! El código HTML generado es:

<thead><tr><td>Nombre</td><td>Precio</td></tr></thead>
<tr><td>PS3</td><td>300</td></tr>
<tr><td>XBox360</td><td>150</td></tr>
<tr><td>Wii</td><td>100</td></tr>

Guay, no?

Podríamos “complicar” un poco el helper, para que desde los templates supiesemos si estamos en una fila par o impar y así aplicar clases… Para ello nos basta con declarar una clase adicional en nuestor helper:

public class RepeaterItem<TItem>
{
    public int Index { get; private set; }
    public bool IsEven { get { return Index % 2 == 0; } }
    public TItem Item { get; private set; }

    public RepeaterItem(TItem item, int index)
    {
        Index = index;
        Item = item;
    }
}

Esa clase simplemente contiene el índice del elemento actual, el propio elemento y una propiedad que indica si es par o no.

Ahora modificamos el helper para pasarle al template body un objeto RepeaterItem<TItem>:

public static class Repeater
{
    public static IHtmlString Repeat<TItem>(
        IEnumerable<TItem> items,
        Func<dynamic, HelperResult> header,
        Func<RepeaterItem<TItem>, HelperResult> body,
        Func<dynamic, HelperResult> footer
        )
    {
        var builder = new StringBuilder();
        if (header != null)
        {
            builder.Append(header(null).ToHtmlString());
        }

        var count = 0;
        foreach (var item in items)
        {
            var repeaterItem = new RepeaterItem<TItem>(item, count++);
            builder.Append(body(repeaterItem).ToHtmlString());
        }
        if (footer != null)
        {
            builder.Append(footer(null).ToHtmlString());
        }

        return MvcHtmlString.Create(builder.ToString());
    }
}

Los cambios básicamente son declarar el template domo Func<RepeaterItem<Titem>> y cuando invocamos el template, crear antes un objeto RepeaterItem y pasárselo como parámetro.

Finalmente ahora debemos modificar la vista, ya que el parámetro @item de nuestro template es ahora un RepeaterItem<TItem>:

@Repeater.Repeat(Model, 
    @<thead><tr><td>Nombre</td><td>Precio</td></tr></thead>, 
    @<tr style="@(item.IsEven ? "background-color: white" : "background-color:pink")">
    <td>@item.Item.Nombre</td><td>@item.Item.Precio</td></tr>, 
    null)

Fijaos como dentro del template body puedo preguntar si el elemento actual es par (@item.IsEven y acceder al propio elemento @item.Item). En este caso uso @item.IsEven para cambiar el color de fondo de la fila:

Y listos! Espero que esos dos posts sobre templates Razor os hayan parecido interesantes!

Un saludo a todos! ;-)

PD: Como siempre… eso es un crosspost desde mi blog en geeks.ms!

ASP.NET MVC3: Razor Templates

2011-01-25T16:41:00.001+01:00

Muy buenas!

En este post quiero comentaros una característica de Razor que yo considero que es una auténtica pasada: los templates.

Básicamente el meollo de todo está en la posibilidad de guardar el resultado de un parseo de Razor en un Func<T, HelperResult> siendo T el tipo del modelo que renderiza el template.

Veámoslo con código:

@{
    Func<string, HelperResult> h =
        @<h2>Esto es un template al que se le han pasado los datos: @item</h2>
    ;
}
<p>
     Renderizamos el template: @h("datos")
</p>

Fijaos como nos guardamos en una Func<string, HelperResult> el resultado de renderizar un template razor (en este caso el template <h2>…</h2>). Fijaos en tres detalles:

Dado que la variable h está declarada como Func<string, HelperResult> el tipo del modelo en este template es “string”

Para acceder al modelo que se pasa al template se usa @item

Al final del template Razor ponemos un ; (eso es una declaración C# y como tal debe terminar en punto y coma).

Luego más adelante renderizamos el template, con el código: @h("datos")

Eh!! Eso no es lo mismo que @helper?

Si conoces @helper te puede parecer que esto no es muy novedoso. Con @helper podemos crear helpers inline de la siguiente manera:

@helper h2(string s) {<h2>Esto es un helper: @s</h2>}

Y lo podíamos invocar con:

@h2("ufo")

Por lo que parece que viene a ser lo mismo. Y es que, en el fondo, ambas construcciones devuelven un HelperResult.

Nota: Si quieres más información sobre @helper, léete el post que hizo el maestro hace algún tiempecillo: http://www.variablenotfound.com/2010/11/y-mas-sobre-helpers-en-razor.html

Lo interesante no es que ambas construccione se parezcan, lo que quiero recalcar es que…

… Los templates son Func<T, HelperResult>!

Lo pongo así en negrita porque eso es importante, y a la vez me sirve de título. Si los templates Razor son Func<T, HelperResult>… cualquier método que reciba un Fun<T, HelperResult> puede recibir un template Razor…

… Incluídos los helpers!

@helper Repeater(int count,Func<dynamic, HelperResult> template, string data) {
    <ul>
    @for (int idx=0; idx<count; idx++)
    {
        <li>@template(new { Text = data, Index = idx })</li>
    }
    </ul>   
}

@Repeater(10, @<span>@item.Text (item: #@item.Index)</span>, "Ufo")

En este código:

Declaramos un helper, llamado Repeater que acepta tres parámetros:
1. Un entero
2. Un Func<dynamic, HelperResult> que por lo tanto podrá ser un template Razor
3. Una cadena

El helper se limita a crear una lista y luego:
1. Crea tantos <li> como indica el paràmetro count y en cada id
  1. Evalúa el segundo parámetro (que es el Func) y le pasa como parámetro un objeto anonimo con dos propiedades (Text e Index), donde Text es el tercer parámetro que recibe (y index el valor de la iteración actual).

Cuando invocamos al helper, le pasamos como primer parámetro el número de repeticiones, como segundo parámetro un template de Razor. Fijaos que dentro de dicho template:
1. Accedemos a las propiedades @item.Text y @item.Index. Eso podemos hacerlo porque hemos declarado el tipo del modelo de dicho template como dynamic y por eso nos compila (y nos funciona porque el helper cuando invoca el template crea esas propiedades en el objeto anónimo).

El código HTML generado por dicha llamada al helper Repeater es:

<ul>
    <li> <span>Ufo (item: #0)</span></li>
    <li> <span>Ufo (item: #1)</span></li>
    <li> <span>Ufo (item: #2)</span></li>
    <li> <span>Ufo (item: #3)</span></li>
    <li> <span>Ufo (item: #4)</span></li>
    <li> <span>Ufo (item: #5)</span></li>
    <li> <span>Ufo (item: #6)</span></li>
    <li> <span>Ufo (item: #7)</span></li>
    <li> <span>Ufo (item: #8)</span></li>
    <li> <span>Ufo (item: #9)</span></li>
</ul>

Espero que el post os haya resultado interesante!!! ;-)

Saludos!

PD: Como siempre… otro crosspost desde mi blog en geeks.ms!

ASP.NET MVC: Como recuperar un dato de una cookie para cada petición… Una alternativa ¿igual?

2011-01-19T11:07:00.001+01:00

Muy buenas! Hace algunos días escribí el post ASP.NET MVC: Como recuperar datos de una cookie en cada petición, donde mostraba el uso de un route handler propio para recuperar los datos de una cookie y colocarlos en el Route Data. En el ejemplo era una cookie de cultura de la aplicación, pero se puede aplicar a lo que queráis.

Lo que más me gusta de ASP.NET MVC es que muy expandible, que muchas cosas pueden hacerse de más de una forma. Pues bien, una de las novedades más interesantes de MVC3 (al margen de Razor) son los action filters globales.

En este post os propongo una solución alternativa (aunque ya veremos que tiene una ligerísima diferencia) al mismo problema. La diferencia es que no se debe alterar la tabla de rutas para nada. Y dicha solución pasa por usar un action filter global.

Una de las cosas que en MVC nos debe quedar claro es que cuando repitamos muchas veces un mismo código de un controlador debemos considerar de ponerlo en un Action Filter. El “problema” está que los action filters deben aplicarse controlador a controlador (o acción a acción). Si tenemos un filtro que debe aplicarse a todos los controladores podemos considerar crear una clase base que lo tenga y heredar todos los controladores de ella…

… o al menos eso era así antes de MVC3.

Con MVC3 y los filtros globales podemos aplicar un filtro a todas las acciones de todos los controladores. Y todo ello con una sola línea en global.asax. Es brutal!

El filtro global…

Lo bueno es que los filtros globales se implementan igual que los filtros no globales clásicos que teníamos en MVC2. En este caso la implementación es super sencilla:

public class CookieCultureFilterAttribute : ActionFilterAttribute
{
    public override void OnActionExecuting(ActionExecutingContext filterContext)
    {
        var cultureCookieVal = GetCultureFromCookie(filterContext.HttpContext.Request.Cookies);
        var culture = new CultureInfo(cultureCookieVal);
        filterContext.RouteData.Values.Add("culture", cultureCookieVal);
        Thread.CurrentThread.CurrentCulture = culture;
        Thread.CurrentThread.CurrentUICulture = culture;
    }

    private string GetCultureFromCookie(HttpCookieCollection cookies)
    {
        var retValue = "ca-ES";
        if (cookies.AllKeys.Contains("userculture"))
        {
            retValue = cookies["userculture"].Value;
        }
        return retValue;
    }
}

El código es trivial: derivo de ActionFilterAttribute (clase que ya existía) y redefino el método OnActionExecuting que se ejecuta antes de ejecutar la acción del controlador. En este método tengo el código para leer la cookie de cultura (exactamente lo mismo que tenía antes en el Route Handler).

Activar el filtro global

Os dije que era una sóla línea en global.asax, verdad? Pues concretamente esta:

GlobalFilters.Filters.Add(new CookieCultureFilterAttribute());

Otra opción es colocar esa línea dentro de la función RegisterGlobalFilters que crea el VS2010, aunque entonces no es necesario usar la clase GlobalFilters (usad en su lugar el parámetro filters):

filters.Add(new CookieCultureFilterAttribute());

Y ya está. Nada más. Antes de cada acción de cualquier controlador se ejecutará el código de nuestro filtro global. No es necesario modificar la tabla de rutas para añadir nuestro route handler.

¿Puedo usar el filtro en una aplicación MVC2?

Si, si que puedes, pero entonces debes:

Aplicarlo en cada controlador (usando [CookieCultureFilter] antes de cada acción o cada controlador que quieras que use la cookie).

Derivar todos tus controladores de un controlador base que tenga [CookieCultureFilter] aplicado.

Y lo más importante… ¿Ambas soluciones son equivalentes?

Pues NO. Ambas soluciones no son equivalentes… En el caso del post anterior, si recordáis, si declaraba un parámetro culture en una acción, recibía el valor de la cookie, ya que el route handler me añadía este parámetro en el RouteData. Pues bien, eso dejará de funcionar. Es decir, en este caso la acción:

public ActionResult Foo(string culture)
{
}

que en el post anterior recibía el valor de la cookie en culture, con esa nueva aproximación siempre recibirá null.

¿Y por que si mi filtro también añade en el RouteData el valor de la cookie? Pues muy sencillo: el Model Binder (que se encarga de hacer binding a los parámetros de las acciones) se ejecuta antes que el filtro. Simplificando, el flujo de ejecuciones sería:

Route Handler

Model Binder

Action Filters

Acción del controlador

En este caso, estamos añadiendo un valor en el RouteData después de que el Model Binder haya actuado. Por eso el parámetro no tendrá el valor. Eso no quita que desde el controlador lo podáis consultar (tenéis acceso al RouteData).

Y con esto termino… espero que el post os haya ayudado un poco más a entender como funciona MVC y ver distintas alternativas de cómo hacer las cosas!

PD: Eso es otroooooooooooooooooo crosspost desde mi blog de geeks.ms

ASP.NET MVC: Como recuperar un dato de una cookie para cada petición…

2011-01-14T13:42:00.001+01:00

EEhhhmm… bueno, no se me ocurre un título mejor. Este post nace gracias a un tweet de Lluis Franco. En el tweet Lluís preguntaba dónde guardar la cultura de una aplicación MVC si no se podía poner en la URL. Después de varios tweets comentando algunas cosillas yo he respondido diciendo que veía dos opciones: o en una cookie o en la base de datos. Una de las cosas que más me gustan de HTTP es que es simple: no hay muchas maneras de pasar estado entre cliente y servidor ;-)

En este post vamos a ver como podemos solucionar fácilmente el problema asumiendo que se guarda la cultura del usuario en una cookie.

De mi tweet, la parte importante es la segunda: independizar a los controladores de donde esta la cultura de la aplicación. Ya lo he comentado en varios posts: evitad acceder desde los controladores a objetos que dependen de HTTP: sesión, aplicación, cache y… cookies.

En un post anterior ya comenté como usar un value provider para hacer binding de datos de una cookie a un controlador. Esa es una buena solución si los datos de la cookie se usan en algunas pocas acciones de un controlador. Pero ese no es nuestro caso ahora: ahora queremos que la cultura se establezca siempre, para todas las acciones de todos los controladores.

La solución en este caso pasa por un Route Handler nuevo. Los route handlers son los objetos que se encargan de procesar las rutas (crear los controladores y cederles el control). Son pues objetos de bajo nivel. Cuando la tabla de rutas enruta una URL para ser procesada por una ruta concreta, se usa el RouteHandler asociado a dicha ruta para crear toda la infrastructura que MVC necesita para procesar la petición.

Recordad que la tabla de rutas se define en Global.asax y que por defecto tiene el siguiente código:

public static void RegisterRoutes(RouteCollection routes)
{
    routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
    routes.MapRoute(
        "Default", // Route name
        "{controller}/{action}/{id}", // URL with parameters
        new { controller = "Home", action = "Index", id = UrlParameter.Optional } // Parameter defaults
    );
}

Aquí no estamos especificando ningún route handler, por lo que se usará el que tiene MVC por defecto… Pero como (casi) todo en MVC lo podemos cambiar :)

En lugar de usar el método MapRoute (que por si alguien no lo sabe es un método de extensión) podemos crear un objeto Route y añadirlo directamente a la tabla de rutas. El constructor de Route tiene un parámetro que es de tipo IRouteHandler y que es el route handler para esta ruta. Así que puedo transformar la tabla de rutas anterior en esta:

public static void RegisterRoutes(RouteCollection routes)
{
    routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

    routes.Add("Default", new Route("{controller}/{action}/{id}", 
        new CultureRouteHandler())
                {
                    Defaults = new RouteValueDictionary(
                        new
                            {
                                controller = "Home", action = "Index", id = UrlParameter.Optional
                            })
                });
}

Ambas son equivalentes, salvo que esta usará un objeto de tipo CultureRouteHandler para procesar las peticiones.

Ahora vamos a ver como es el CultureRouteHandler:

public class CultureRouteHandler : MvcRouteHandler
{
    protected override IHttpHandler GetHttpHandler(System.Web.Routing.RequestContext requestContext)
    {
        var cultureCookieVal = GetCultureFromCookie(requestContext.HttpContext.Request.Cookies);
        var culture = new CultureInfo(cultureCookieVal);
        requestContext.RouteData.Values.Add("culture", cultureCookieVal);
        Thread.CurrentThread.CurrentCulture = culture;
        Thread.CurrentThread.CurrentUICulture = culture;
        return base.GetHttpHandler(requestContext);
    }

    private string GetCultureFromCookie(HttpCookieCollection cookies)
    {
        var retValue = "ca-ES";
        if (cookies.AllKeys.Contains("userculture"))
        {
            retValue = cookies["userculture"].Value;
        }
        return retValue;
    }
}

En este caso derivo de MvcRouteHandler (como casi siempre en MVC es mucho más sencillo derivar de alguna clase base que implementar la interfaz entera), y en el método GetHttpHandler lo que hago es llamar al método de la clase base pero antes:

Recupero el valor de la cookie de cultura

Guardo este valor en el route data con el nombre culture (por si alguien quiere consultarlo)

Creo un CultureInfo a partir de los datos de la cookie y establezco la cultura del thread actual a este valor: así cualquier mecanismo que tenga de “localización” debería funcionar igualmente.

Finalmente para probar el tema me he creado un pequeño controlador:

public class HomeController : Controller
{
    [OutputCache(NoStore = true, Location = OutputCacheLocation.None)]
    public ActionResult Index()
    {
        return View();
    }

    public ActionResult SetCookie(string id)
    {
        if (!string.IsNullOrEmpty(id))
        {
            this.ControllerContext.HttpContext.Response.Cookies.Add(new HttpCookie("userculture", id));
        }
        return RedirectToAction("Index");
    }
}

La acción /Home/Index simplemente retorna una vista. La acción /Home/SetCookie/id establece la cookie de cultura (se supone que el id es válido, algo así como /Home/SetCookie/es-ES p.ej.).

La vista que devuelve /Home/Index simplemente muestra la cultura actual:

<p>
    Cultura actual: @System.Threading.Thread.CurrentThread.CurrentUICulture.ToString();
</p>

Bonus track: Y si quiero que algún controlador reciba la cultura actual como parámetro de alguna de sus acciones?

Bien, recordad que hemos hecho que el route handler guardase el valor de cultura en los route values. MVC tiene un value provider que permite realizar bindings desde los route values hacia los controladores. Guardábamos el valor con el nombre “culture” así que nos basta con:

public ActionResult Foo(string culture)
{
    // Código...
}

El parámetro culture tiene el valor de la cultura.

Si quieres saber exactamente cómo reciben los datos los controladores, hace algún tiempecillo escribí un post al respecto.

De esa manera conseguimos lo que yo decía en mi tweet: agnostizar los controladores de dónde se guarda la cultura!

Un saludo!

PD: Esto es (como siempre, vamos) un crosspost desde mi blog en geeks.ms

ASP.NET MVC3: Validación remota

2011-01-14T10:26:00.001+01:00

Muy buenas!

Una de las novedades que nos trae ASP.NET MVC3, con respecto a MVC2 es poder usar fácilmente la validación remota: eso es, desde cliente llamar a un método del servidor que nos diga si un dato (entrado p.ej. en un campo de texto es válido o no). Y cuando digo fácilmente me refiero a fácilmente, muy fácilmente.

Vamos a ver un ejemplo: para ello vamos a modificar la aplicación de ejemplo que crea MVC3 para que al darnos de alta, consulte si el usuario ya existe y si es el caso no nos deje. Os recuerdo que esa validación es Ajax, eso significa: el campo de texto pierda el foco se realizará la petición (en background) al servidor que comprobará si el usuario entrado ya existe y si es así mostrará un error en el campo de texto asociado.

Vamos pues, a verlo paso a paso ;-)

1. Viendo que nos genera MVC3

Para empezar creamos un nuevo proyecto ASP.NET MVC3. Cuando os pida el template, usad el de Internet Application (no uséis el Empty). De esa manera MVC3 nos crea el esqueleto de la aplicación inicial:

El fichero AccountModels.cs tiene distintos Viewmodels que usan las acciones del controlador Account. La acción que da de alta un usuario es Register que está definida en el controlador Account:

[HttpPost]
public ActionResult Register(RegisterModel model)
{
    // Código...
}

La acción usa la clase RegisterModel que es uno de los viewmodels definidos en AccountModels.cs:

public class RegisterModel
{
    [Required]
    [Display(Name = "User name")]
    public string UserName { get; set; }

    [Required]
    [DataType(DataType.EmailAddress)]
    [Display(Name = "Email address")]
    public string Email { get; set; }

    [Required]
    [ValidatePasswordLength]
    [DataType(DataType.Password)]
    [Display(Name = "Password")]
    public string Password { get; set; }

    [DataType(DataType.Password)]
    [Display(Name = "Confirm password")]
    [Compare("Password", ErrorMessage = "The password and confirmation password do not match.")]
    public string ConfirmPassword { get; set; }
}

2. Habilitando la validación remota

La validación remota en MVC3 se habilita, como el resto de validaciones, usando DataAnnotations, concretamente con el atributo Remote. En nuestro caso queremos habilitar la validación remota sobre la propiedad UserName. Para ello añado el atributo Remote:

[Required]
[Display(Name = "User name")]
[Remote("CheckUserAvailability", "Account", ErrorMessage = "This user name is not allowed.")]
public string UserName { get; set; }

El primer parámetro es la acción que va a validar el campo, la segunda es el controlador. Finalmente ponemos el mensaje de error (igual que las otras validaciones).

3. Creando el código de validación

Finalmente tenemos que crear la acción del controlador:

[OutputCache(Location = OutputCacheLocation.None, NoStore = true)]
public ActionResult CheckUserAvailability(string username)
{
    var validUserName = Membership.FindUsersByName(username).Count == 0;
    return Json(validUserName, JsonRequestBehavior.AllowGet);
}

Fijaos lo simple que es: Usamos el membership provider para ver si existe algún otro usuario con el mismo nombre, y devolvemos un booleano (codificado en json). El uso de [OutputCache] es para evitar que MVC me cachee los resultados de las peticiones.

Y listos! Con eso ya hemos terminado.

Podemos ejecutar la aplicación, registrar un usuario y luego intentar darnos de alta de nuevo y veremos el error:

4. Y que pasa “en la trastienda”?

Si inspeccionamos las peticiones veremos que cada vez que cambia el texto se realiza una petición Ajax. Esta vez en lugar de firebug he usado las Developer Tools de IE9 (pulsar F12 para que os aparezcan):

Estas son las peticiones que se realizan si entro “eiximenis” en el campo de nombre de usuario. Si las contáis veréis que faltan peticiones. Eso es simplemente he pulsado dos teclas muy rápido y las peticiones supongo que no se encolan

Si miramos los detalles de una petición vemos lo siguiente:

Fijaos en el primer campo (Request) me indica la URL de la petición. En mi caso es /Account/CheckUserAvailability?UserName=eiximenis

Es decir se pasa el valor por querystring (eso no es problema alguno para MVC que soporta el binding de datos en el querystring desde siempre).

5. Y qué código me genera eso en el navegador?

Recordáis que MVC3 apuesta fuertamente por el unobstrusive javascript? Pues eso es lo que nos genera:

<input data-val="true" 
data-val-remote="This user name is not allowed." 
data-val-remote-additionalfields="*.UserName" 
data-val-remote-url="/Account/CheckUserAvailability" 
data-val-required="The User name field is required." 
id="UserName" name="UserName" type="text" value="" />

Precioso no? Nada de código javascript mezclado por ahí que “ensucie” el html: sólo atributos.

Los atributos data-val-remote-* son los que controlan la validación remota. Para que eso funcione, es necesario que los scripts siguientes estén referenciados:

jquery-1.4.4.min.js

jquery.validate.min.js

jquery.validate.unobtrusive.min.js

Yo los tengo siempre colocados en mi página Master principal (Views/Shared/_Layout.cshtml si usas Razor).

6. Controlando algunos aspectos “avanzados”

Vamos a ver como controlar algunos aspectos más de la validación remota. P.ej. te puede interesar que la llamada a la acción de validación (CheckUserAvailability) se realice via POST y no via GET. Para ello simplemente usa la propiedad HttpMethod del atributo Remote:

[Remote("CheckUserAvailability", "Account",
    HttpMethod = "POST", ErrorMessage = "This user name is not allowed.")]

Eso añade el atributo data-val-remote-type="POST" al campo HTML generado lo que fuerza que la petición sea usando POST.

Otra cosa interesante es que podemos enviar más de un parámetro a la acción quen realiza la “validación remota”. P.ej. imaginad que a CheckUserAvailability le queremos también pasar el password que ha introducido el usuario (vale, no tiene lógica en ese ejemplo, pero imaginadlo igual :p).

Para ello podemos usar la propiedad AdditionalFields del atributo Remote:

[Remote("CheckUserAvailability", "Account", HttpMethod = "POST",
    AdditionalFields = "Password",
   ErrorMessage = "This user name is not allowed.")]
public string UserName { get; set; }

Ahora si miramos de nuevo lo que nos manda la petición veremos que junto al campo UserName nos manda el valor del campo Password:

Tened presente que el valor de Password puede ser vacío (el usuario puede no haber introducido nada allí todavía). Pero lo importante de esto es que las validaciones remotas no están limitadas a validar UN SOLO campo.

Y con eso terminamos el post de las validaciones remotas en ASP.NET MVC3… Como podeis ver, es un método sumamente potente y sumamente fácil!

Un saludo! ;)

PD: Para variar eso es un crosspost desde mi blog en geeks.ms!

ASP.NET MVC: Binding de datos de sesión a controladores

2011-01-03T11:11:00.001+01:00

Muy buenas! Que tal el fin de año? Empachados con turrones, polvorones y demás? En fin, vamos a inaugurar el 2011 y que mejor manera que hacerlo que con un post! ;-)

En realidad hubiese querido que este post fuese el último del año anterior, pero no puede publicarlo antes por problemas logísticos. La idea del post surge de un tweet que publicó Luis Ruiz Pavón. Su pregunta era que tal acceder a la sesión desde un Model Binder para poner datos a disposición de los controladores. Mi respuesta fue que yo usaría un value provider, y así llegamos a este post.

Para conseguir binding de los datos de la sesión a los parámetros de un controlador no es necesario crear ningún Model Binder. En MVC2 se introdujo un concepto nuevo (del que ya he hablado varias veces por aquí) que se llama ValueProvider y que es el encargado de acceder donde están los datos y ponerlos a disposición de los Model Binders. Si ignoramos los value providers y hacemos un model binder que acceda a la sesión, entonces realmente nuestro model binder hace dos cosas:

Ir donde están los datos (la sesión) y recogerlos
Enlazar los datos con los parámetros de los controladores

Según la arquitectura de ASP.NET MVC los model binders sólo se encargan de lo segundo, y son los value providers quienes se encargan de lo primero. Así, pues, tened presente la regla:

Si lo que queréis canviar es cómo se enlazan los datos (vengan de donde vengan) a los controladores: cread un model binder
Si lo que queréis es modificar de dónde se obtienen los datos que se enlazan a los controladores: usad un value provider.

En nuestro caso, tal y como se enlazan los valores a los controladores ya nos va bien (el DefaultModelBinder es realmente bueno en su tarea), sólo que queremos que si un dato está en la sesión se coja de allí: necesitamos un value provider nuevo.

Factoría de value providers

En ASP.NET MVC los value providers se crean siempre mediante una factoría y lo que realmente registramos en el runtime son esas factorías. En cada petición ASP.NET MVC le pide a las distintas factorías que creen los value providers necesarios.

Así pues lo primero va a ser crear nuestra factoría, que devolverá objetos de nuestro value provider vinculado a sesión:

class SessionValueProviderFactory : ValueProviderFactory
{
    public override IValueProvider GetValueProvider(ControllerContext controllerContext)
    {
        return new SessionValueProvider(controllerContext.HttpContext.Session);
    }
}

Simplemente debemos derivar de ValueProviderFactory y en el método GetValueProvider devolver una instancia de nuestro value provider. En mi caso devuelvo una instancia del SessionValueProvider y le paso la sesión en el constructor.

Debemos registrar esa factoría de value providers en el runtime de ASP.NET MVC. Para ello en el Global.asax basta con meter la siguiente línea (usualmente en el Application_Start):

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

El value provider

Crear un value provider es “tan sencillo” como implementar la interfaz IValueProvider. De todos modos debemos conocer un poco como funcionan los model binders a los que debemos proporcionar los valores.

Los value providers vienen a ser como un “diccionario enorme” que los model binders consultan cuando quieren obtener un dato. Debemos saber cómo (“con que clave”) nos va a pedir el model binder los datos y como debemos dárselos. En un post mío de hace tiempo ya comenté como funciona el DefaultModelBinder, y allí cuento también la interacción entre el DefaultModelBiner y los value providers.

En fin, que todo ese rollete es para comentaros que muchas veces en lugar de implementar IValueProvider desde cero, es mucho mejor derivar de alguna de las clases que ya hay hechas, y hay una en concreto que nos viene al pelo: DictionaryValueProvider<TValue>. Esta clase implementa un value provider cuya fuente de datos es un diccionario cuyos valores son de tipo TValue. Y que es la sesión en el fondo sinó un gran diccionario cuyos valores son de tipo object?

Así pues creamos nuestra clase que derive de DictionaryValueProvider y lo único que tenemos que hacer es pasarle a nuestra clase base el diccionario que debe usar, que construimos a partir de la sesión:

class SessionValueProvider : DictionaryValueProvider<object>
{
    public SessionValueProvider(HttpSessionStateBase session)
        : base(CreateDictionary(session), CultureInfo.CurrentCulture)
    {

    }

    private static IDictionary<string, object> CreateDictionary(HttpSessionStateBase session)
    {
        var entries = session.Keys.Cast<string>().ToDictionary(key => key, key => session[key]);
        return entries;
    }
}

Trivial no? El método CreateDictionary simplemente crea un IDictionary a partir de los datos de la sesión.

Y listos! Hemos terminado, No necesitamos hacer nada más para que el binding de objetos de sesión funcione. El requisito para que el binding se efectúe es el de siempre: que el nombre del parámetro en la acción del controlador tenga el mismo nombre que la clave de sesión:

public class SessionController : Controller
{
    public ActionResult Put()
    {
        Session["ufo"] = "String en sessión";
        Session["complex"] = new Foo()
                                 {
                                     Cadena = "Una cadena en objeto complejo",
                                     Entero = 100,
                                     Lista = new List<int>() {1, 1, 3, 5, 8, 13}
                                 };
        return View();
    }
    public ActionResult Get(string ufo)
    {
        ViewData["data"] = ufo;
        return View();
    }

    public ActionResult GetClass(Foo complex)
    {
        return View(complex);
    }
}

En este controlador la acción Put coloca dos datos en la sesión: una cadena con clave “ufo” y un objeto de una clase llamada Foo, con clave “complex”. Las dos acciones restantes (Get y GetClass) usan el binding y obtienen los datos de la sesión.

Ventajas de usar el binding para obtener los valores

La ventaja principal de usar el binding para obtener los valores en lugar de acceder a la sesión directamente es que desacopla el código de las acciones de la sesión de HTTP. En definitiva, si quiero probar si la acción Get funciona correctamente, p.ej. usando un unit test, me basta con pasarle una cadena cualquiera. Si en el código de la acción accediese a la sesión debería tener acceso a la sesión (desde la prueba) y rellenarla.

Espero que os sea útil!

Un saludo!

PD: Teneis un proyecto en VS2010 con MVC2 con el código de dicho post en mi skydrive: http://cid-6521c259e9b1bec6.office.live.com/self.aspx/BurbujasNet/ZipsPosts/MvcSessionBinding.zip

PD2: Como siempre: esto es un crosspost desde mi blog bn geeks.ms. Pásate por allí mejor!

Opinión: Var o no var… esa es la cuestión.

2010-12-21T15:01:00.001+01:00

Hola a todos! Desde hace algunos días estoy usando Resharper. La verdad no era, como decirlo, muy proclive para instalármelo, ya que había tenido no muy buenas experiencas con CodeRush. Seguramente no eran culpa de CodeRush sinó mías, pero bueno… Al final me lo instalé y debo decir que estoy gratamente sorprendido: Es una auténtica maravilla.

Una cosa interesante de Resharper es que te hace sugerencias (que puedes desactivar si quieres, por supuesto) sobre como codificar mejor. Y una de las sugerencias es usar var siempre que se pueda:

Fijaos que incluso en un caso trivial como int i=0; nos recomienda que usemos var.

Nota: Primero una pequeña aclaración sobre var: Por si acaso… Recordad que var no es tipado dinámico, ni late-binding ni nada parecido a esto. Var simplemente le indica al compilador que infiera él el tipo de la variable. Pero la variable tiene un tipo concreto y lo tiene en tiempo de compilación. Por lo tanto olvidad todos vuestros prejuicios (si los tenéis) sobre tipos dinámicos.

Hay tres corrientes de opinión al respecto de cuando usar var: Hay gente que opina que debe usarse sólo cuando es necesario (cuando se trabaja con objetos anónimos).

Otros opinan que cuando el tipo ya aparece en la lína de código puede usarse var. Es decir, admiten esto:

var dict = new Dictionary<int, string>();

Porque el tipo de la variable ya aparece en el new. Pero no admiten lo siguiente:

var result = stockManager.GetStocks();

Porque, viendo el código: como se puede saber el tipo de result? (Debes irte a ver que devuelve el método GetStocks).

Por último el tercer grupo de opinión está a favor de usar var siempre. Incluso en los casos más triviales.

Por curiosidad:

La msdn se situa en el primer grupo de opinión (literalmente dice “the use of var does have at least the potential to make your code more difficult to understand for other developers. For that reason, the C# documentation generally uses var only when it is required” - http://msdn.microsoft.com/en-us/library/bb384061.aspx).

Resharper se sitúa en el tercer grupo, como hemos visto

Yo me situaba en el segundo grupo de opinión.

¿Que aporta usar siempre var?

Que Resharper me estuviese continuamente insistiendo en usar var me hizo pensar en el por que de esa razón. Así que lo que hice fue probar y hacerle caso. Y empecé a usar var en todos los sitios. A ver que ocurría.

Y ocurrió una cosa interesante…

Al usar var continuamente pierdes el tipo de la variable de forma visual (es decir no sabes de que tipo es sólo viendo esa línea de código) y entonces te das cuenta de una cosa: que muchos nombres de variables aportan muy poca información sobre que hace realmente la variable. Los detractores de var dicen que puede complicar la lectura de código… pero que es más dificil de entender, esto:

Player plr = GetCurrentPlayer();
Location l = plr.GetCustomLocation();
// Varias líneas de código hablando de "l" y "plr"

o esto:

var player = GetCurrentPlayer();
var location = player.GetCustomLocation();
// Varias líneas de código hablando de "location" y "player"

El tema está en que la variable la declaras en una línea, y la usas en varias más. Evidentemente, si no usas var, la línea que declara la variable te da más información (exactamente el tipo de la variable), información que pierdes si usas var. Pero, como te das cuenta que estás perdiendo esta información, lo que haces es usar lo que resta de la línea para aumentar la claridad. Y que es lo que queda? El nombre de la variable.

Al usar var en todos los sitios te fuerzas a poner nombres más declarativos a tus variables, que expresen lo que la variable hace. Y todos sabemos que esa es una muy buena práctica. Y a veces no la seguimos, y una de las razones es que al tener una línea tipo:

Location l = new Location();

Mentalmente piensas: <<Ya se ve que “l” es una Location. Ya queda claro.>>

Pero no es cierto, porque al cabo de unas cuantas líneas te aparece una “l” y tienes que recordad que era una Location.

Mientras que si usas var, cuando escribes la línea tiendes a usar nombres más descriptivos, porque escribir:

var l = new Location();

Hace como daño a la vista :)

Así que la sugerencia de usar var siempre, personalmente no me parece muy desacertada, y creo que voy a tomar esa opción de ahora en adelante.

Pero… Y vosotros? ¿Que opináis al respecto?

Un saludo!

PD: También creo que hay otra razón para que Resharper nos guie a usar siempre var y es que el código con var es más fácil de refactorizar (menos cambios) que el que usa declaraciones explícitas.

PD2: Como no… otro crosspost desde mi blog de geeks.ms!

ASP.NET: Obtener el ID del usuario actual

2010-12-16T14:21:00.001+01:00

Buenas!

No se vosotros, pero yo cuando desarrollo mis aplicaciones, si uso FKs de la otabla de usuarios, las hago en base al ID del usuario, nunca en base a su nombre. Así pues, saber el ID del usuario actualmente autenticado en mi aplicación es algo fundamental.

Primero, para saber el nombre del usuario autenticado podemos usar:

string userName = HttpContext.Current.User.Identity.Name;

El tema está en que las mentes pensantes que parieron el sistema de proveedores de autenticación en ASP.NET no tuvieron a bien a poner un campo para guardar el ID.

Por suerte obtenerlo es trivial:

int i = (int)Membership.GetUser().ProviderUserKey;

Ojo con ese código: Yo uso un membership provider propio, ya que mi base de datos usa ints para los IDs de usuarios. Si usáis el membership provider que viene por defecto en ASP.NET, el cast lo debéis hacer a Guid y no int.

Bueno todo muy bonito, pero antes que descorchéis el cava: eso hace una llamada a la base de datos. Además se trae todos los campos del registro correspondiente de la tabla de usuarios (que si usáis el membership provider que viene por defecto tiene la hostia y pico). O sea que cuidado con usar eso a mansalva… :)

Eeeerrr… ¿se puede SIN necesidad de acceder a la base de datos?

Bueno… esa es la gran pregunta, no nos vamos a engañar ;-) Hay varias maneras de poder acceder al ID del usuario sin hacer un round-trip a la base de datos, pero a si a bote pronto se me ocurren dos:

Guardarlo en una variable de sesión: Podemos guardar el ID en una variable de sesión y consultarla cuando la necesitamos. Para una escalabilidad máxima podéis no usar sticky sessions y en el Session_Start guardar dicha variable con el ID. Si no usáis sticky sessions un mismo usuario puede iniciar sesión en varios IIS a la vez, pero en nuestro caso no es problemático (simplemente se consultará el ID del usuario cada vez que inicie sesión). Eso sí, estoy asumiendo que no guardáis nada más en la sesión (es decir que funcionalmente no dependéis de la sesión).

Guardarlo en la cookie de autenticación del usuario. Esto no es, ni de lejos tan sencillo como el punto anterior, pero ya que hemos llegado hasta aquí…

Modificar la cookie de autenticación

Primero debemos hacer que cuando se cree la cookie de autenticación se añada el ID del usuario. En mi caso, como siempre, uso ASP.NET MVC, así que modificaré el código de AccountController (que es el que genera VS). Para aplicaciones webforms ese código debe colocarse cuando se va a hacer login del usuario.

En el código por defecto que genera VS para autenticar un usuario se usa:

public void SignIn(string userName, bool createPersistentCookie)
{
    if (String.IsNullOrEmpty(userName)) throw new ArgumentException("Value cannot be null or empty.", "userName");

    FormsAuthentication.SetAuthCookie(userName, createPersistentCookie);
}

Este código está en la clase FormsAuthenticationService (dentro de AccountsModel.cs) y no tiene ningún secreto: lo que hace es crear la cookie de autenticación de ASP.NET.

En nuestro caso vamos a modificar ese código por el siguiente:

public void SignIn(string userName, bool createPersistentCookie)
{
    if (String.IsNullOrEmpty(userName)) throw new ArgumentException("Value cannot be null or empty.", "userName");
    FormsAuthentication.SetAuthCookie(userName, createPersistentCookie);
    int id = 100;        // Aquí va el ID del usuario que pillaríamos de la BBDD
    string userData = id.ToString();
    FormsAuthenticationTicket ticket = new FormsAuthenticationTicket(1, userName, DateTime.Now, DateTime.Now.AddMinutes(30), createPersistentCookie, userData); 
    string encTicket = FormsAuthentication.Encrypt(ticket); 
    HttpCookie faCookie = new HttpCookie(FormsAuthentication.FormsCookieName, encTicket); 
    HttpContext.Current.Response.Cookies.Add(faCookie);
}

Lo que hacemos es crear una cookie, con datos adicionales (el ID del usuario).

Ahora lo que nos toca es la otra parte: reemplazar el valor de HttpContext.Current.User.Identity por uno propio que tenga el ID. Para ello usamos el evento PostAuthenticate_Request:

protected void Application_PostAuthenticateRequest(object sender, EventArgs e)
{
    HttpCookie authCookie = Request.Cookies[FormsAuthentication.FormsCookieName];
    if (authCookie != null)
    {
        FormsAuthenticationTicket authTicket = FormsAuthentication.Decrypt(authCookie.Value);
        CustomIdentity identity = new CustomIdentity(authTicket.Name, authTicket.UserData);
        GenericPrincipal newUser = new GenericPrincipal(identity, new string[] {});
        Context.User = newUser;
    }
}

Recogemos la cookie de autenticación, desencriptamos el ticket de autenticación por forms y con los datos (el nombre y el UserData) creamos un objeto de tipo CustomIdentity, clase nuestra que nos implementa IIdentity. Luego la incrustamos dentro de un GenericPrincipal y lo establecemos a la propiedad User del HttpContext.

Nota: El segundo parámetro del constructor de GenericPrincipal es el array de roles a los que pertenece el usuario. En mi caso no uso roles, así que le asigno un array vacío.

La clase CustomIdentity es tal y como sigue:

class CustomIdentity : IIdentity
  {

      public CustomIdentity(string name, string id)
      {
          IsAuthenticated = true;
          Name = name;
          Id = Int32.Parse(id);
          AuthenticationType = "Forms";
      }

      public string AuthenticationType { get; private set; }
      public bool IsAuthenticated { get; private set; }
      public string Name { get; private set;}
      public int Id { get; private set; }
  }

De esta manera, ahora podemos al Id del usuario, desde un controlador:

CustomIdentity ci = (CustomIdentity)ControllerContext.HttpContext.User.Identity;
int IdUsuario = ci.Id;

Un misterio con el que me he encontrado es que el código de PostAuthenticateRequest si se pone en AuthenticateRequest (que parece que debería funcionar igual), se queja diciendo que la clase “CustomIdentity” no es serializable. No tengo muy claro porque ocurre eso y eso si que parece ser propio de MVC. Aquí hay más información al respecto: http://stackoverflow.com/questions/1884030/implementing-a-custom-identity-and-iprincipal-in-mvc

Y Listos!

Con esto podemos acceder al ID de nuestros usuarios sin necesidad de usar para nada la base de datos. Además, dado que estamos usando el sistema de autenticación de ASP.NET (no hacemos nada raro), nos siguen funcionando los filtros de autenticación como [Authorize].

Un saludo!

Referencia: http://stackoverflow.com/questions/1064271/asp-net-mvc-set-custom-iidentity-or-iprincipal

PD: Eso es (como siempre) un crosspost desde mi blog en geeks.ms!

Trick: Enviar datos en JSON usando POST

2010-11-23T11:41:00.001+01:00

Muy buenas!

Una de las preguntas que mucha gente se formula cuando empieza a hacer cosillas con ajax y jQuery es ¿Como enviar datos codificados en JSON usando POST?

La verdad es que es muy sencillo, aunque jQuery no proporciona ninguna función por defecto que haga esto. Vamos a ver tres aproximaciones, las dos primeras incorrectas pero que nos acercarán para llegar al final a la una forma correcta de hacerlo.

Aproximación 1: Usando $.post

jQuery tiene una función específica para enviar datos usando post, llamada $.post. Así podriamos pensar que el siguiente método funcionaria:

function JsonPost(data, url, handler)
{
    $.post(url, data, handler);
}

Y luego podríamos llamarlo de la siguiente manera:

// Envia un objeto con propiedades Col y Row a /Map/ViewPort y
// llama a fillMap con el resultado devuelto
JsonPost({ Col: c, Row: r}, "/Map/Viewport", function(data) {
    fillMap(data);
});

Pero eso no realiza una petición JSON. Si usamos, p.ej. Firebug para analizar la petición vemos que lo que se envía al controlador es:

Si os fijáis los datos no están codificados en JSON, sinó en el formato “estándard” (param=value&param=value&…)

Si se lee la documentación de $.post() se ve que acepta un último parámetro datatype, así que podríamos pensar que poniendo dicho parámetro a “json” funcionará, pero no. El parámetro “datatype” indica el tipo de datos esperado de vuelta, no el que se envia.

Resumiendo: $.post() siempre envía los datos en el formato tradicional.

Aproximación 2: Usando $.post() y convertir los datos a Json

De acuerdo, hemos visto que $.post() nos transforma nuestro objeto javascript en la cadena tradicional de param=value&param=value&… Pero si a $.post() se le pasa una cadena la manda tal cual, por lo que si transformamos el objeto javascript a una cadena JSON parece que todo funcionará.

Para transformar un objeto javascript a notación JSON podemos usar el plugin jQuery-Json. Puede haber otros plugins por ahí, pero uséis el que uséis, aseguraros que soporta native json. Native json es una funcionalidad que los nuevos navegadores traen y que se basa en un método llamado JSON.stringify que transforma el objeto pasado a una cadena json. Evidentemente siempre será mucho más rápido si el propio navegador puede hacer esto de forma nativa que si es código javascript que construye la cadena. El plugin jQuery-json usa JSON.stringify si está disponible y sólo en caso de que no exista usa código javascript.

Así pues podríamos modificar nuestra JsonPost para que quede como:

function JsonPost(data, url, handler)
{
    $.post(url,$.toJSON(data), handler);
}

El método $.toJSON es el método proporcionado por el plugin. Ahora sí que estamos usando JSON para enviar los datos:

Ok. Un parentesis: Recordad que MVC2 no tiene soporte directo para realizar binding de datos enviados en JSON. Aunque es muy fácil crearse un Value Provider propio que de soporte a JSON en MVC2. Y recordad que MVC3 ya viene con el soporte por defecto de JSON.

Bien, si usáis un value provider para JSON que os hayais encontrado por “ahí afuera” lo más probable es que no os funcione, es decir que en el controlador no recibáis los datos. Por que? Pues por lo que está marcado en rojo en la imagen antrior: aunque estamos enviando los datos en formato json, el content-type no es correcto. El content-type de JSON es application/json y este es el content-type que suelen mirar los value providers de JSON.

Aproximación 3: Usando $.ajax()

Bien, ya que $.post() no permite especificar el content-type, la tercera y última aproximación es usar $.ajax(), que es la función más personalizable que tiene jQuery para hacer peticiones ajax.

De hecho básicamente lo único que tenemos que cambiar respecto la aproximación anterior es el content-type:

function JsonPost(data, url, handler)
{
    $.ajax(
    {
        url: url,
        type: "POST",
        success: handler,
        data: $.toJSON(data),
        contentType: "application/json"
    });
}

Y lo que nos muestra Firebug de la petición:

Fijaos que ahora el propio Firebug reconoce que la petición es en JSON y me muestra los datos en JSON.

Espero que os sea útil!

Un saludo!

PD: Como no… otro crosspost desde mi blog en geeks.ms!

[Evento] Hasta donde se puede llegar con ASP.NET MVC?

2010-11-19T12:24:00.001+01:00

Muy buenas!

El jueves 2 de diciembre voy a realizar un WebCast para la gente del Lleida DotNetClub sobre ASP.NET MVC.

La idea es empezar desde cero a desarrollar una aplicación ASP.NET MVC y ver hasta donde llegamos. Iremos explorando el framework y viendo paso a paso sus características: controladores, vistas, modelos, vistas parciales, ajax, helpers, inyección de dependencias,…

La idea es que sea 100% Visual Studio, nada de powerpoints que de esto ya se encuentra mucho en la web!

La página de registro está en https://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032471331&EventCategory=4&culture=es-ES&CountryCode=ES

Así que si estás interesado en ver ASP.NET MVC, ya sabes: te esperamos! ;-)

Saludos y gracias a la gente del Lleida DotNetClub por invitarme a dar la charla! :)

PD: Huelga decir que si tienes cualquier comentario sobre algo específico que te gustaría ver en este Webcast coméntalo por aquí y voy a ver como se puede encajar! De lo que se trata es que este Webcast sea interesante para vosotros!

PD2: Pues sí… Eso es oooooooootro crosspost de mi blog de geeks.ms

C# Básico: Covarianza en genéricos

2010-11-18T14:53:00.001+01:00

Muy buenas! Hacía tiempo que no escribía nada de la serie C# Básico. En esta serie voy tratando temas (sin ningún orden en particular) que considero que son fundamentos más o menos elementales del lenguaje. No es un tutorial al uso, cada post es independiente del resto y como digo no están ordenados por nada en particular.

El post de hoy nace a raíz de una pregunta que vi en los foros de msdn (http://social.msdn.microsoft.com/Forums/es-ES/vcses/thread/daf808ed-a0aa-4e1e-88ed-64ee60cce918), donde un usuario preguntaba porque el intentar convertir una List<LogVehiculos> a List<Log> le daba error teniendo en cuenta que LogVehiculos derivaba de Log.

Mi respuesta fue que en C# 3.5 los genéricos no son covariantes, y este post es para explicarlo todo un poco más :)

Antes que nada, covarianza y contravarianza son dos palabrejas muy molonas para explicar dos conceptos que son muy básicos pero que tienen implicaciones muy profundas. El mejor artículo en español que he leído sobre covarianza y contravarianza es el del Doctor (maestros hay algunos, doctores muchos menos) Miguel Katrib que salió publicado en la DotNetMania número 62 y titulado “La danza de las varianzas”. Es un artículo que debe leerse con atención pero sin duda de lo mejorcito que he leído nunca. Este post no entrará ni mucho menos en la profundidad de dicho artículo, así que si os interesa el tema, ya sabeis: haceros con dicha DotNetMania.

En este post nos vamos a centrar sólamente en la covarianza.

Covarianza

Llamamos covarianza a algo muy simple: Cuando permitimos sustituir un tipo D por otro tipo B. Para que eso sea posible debe cumplirse una condición: Que no haya nada que pueda hacerse con B y NO pueda hacerse con D.

Vamos a suponer que tenemos una clase Animal, de la cual deriva la clase Perro:

class Animal
{
   public void Comer() { ... }
   public void Dormir() { ... }
}

class Perro : Animal
{
   public void VigilarCasa() { ... }
}

Si tenemos un método cualquiera que devuelva un perro, nosotros podemos convertir el resultado a un animal:

Perro ComprarPerro() { ... }
// entonces eso es válido:
Animal animal = ComprarPerro();

Eso es covarianza: el poder sustituir la clase derivada (Perro) que devuelve el método con la clase base (Animal). C# soporta covarianza entre una clase derivada y su clase base (como hacen de hecho todos los lenguajes orientados a objetos).

Tiene lógica, porque fijaos que no hay nada que pueda hacerse con un Animal (B) que no pueda hacerse con un Perro (D): Dado que Perro deriva de Animal hereda todos sus métodos y propiedades.

Pero la covarianza se da también en más casos y algunos de ellos están soportados en C#. Veamos…

Covarianza en delegados

Se trata de poder asignar a un delegado que devuelve un Animal un método que devuelve un Perro:

delegate Animal AnimalDelegate();
class Program
{
    static Perro ObtenerPerro() { return new Perro(); }
    static Animal ObtenerAnimal() { return new Animal(); }
    static void Main(string[] args)
    {
        Animal animal = ObtenerPerro();
        AnimalDelegate ad = new AnimalDelegate(ObtenerAnimal);
        AnimalDelegate ad2 = new AnimalDelegate(ObtenerPerro);        
    }
}

Fijaos en la segunda declaración (ad2): Aunque el delegate está declarado para métodos que devuelven un Animal podemos usar este delegate con métodos que devuelvan un Perro. Por eso decimos que los delegates son covariantes en C#.

Covarianza en arrays

El siguiente código en C# funciona y es totalmente válido:

Animal[] animales = new Perro[100];

Es decir podemos asignar un array de Perros a un array de Animales. De nuevo los arrays son covariantes en C#. Esta decisión se tomó en su día para, bueno… luego hablaremos más sobre ella :)

Covarianza en genéricos

El siguiente código no compila en C#:

// error CS0029: Cannot implicitly convert type 'System.Collections.Generic.List<ConsoleApplication8.Perro>' to 'System.Collections.Generic.List<ConsoleApplication8.Animal>'
List<Animal> animales = new List<Perro>();

Es por ello que decimos que los genéricos NO son covariantes en C#.

Y ahora viene la pregunta… ¿por que?

Bien, recordad que si yo quiero sustituir un tipo D por otro tipo B eso significa que en un objeto de tipo D debo poder hacer cualquier cosa que haga en un objeto de tipo B. Es decir, si hay algo, llamémosle f(), que pueda hacer para un objeto de tipo B que no pueda hacer con un objeto de tipo D, no puedo aplicar covarianza… Ya que entonces podría hacer D.f() que no sería válido (recordad que f() es válido para B y no para D).

Cojamos el caso de List<Animal> y List<Perro> (recordad que Perro deriva de Animal). La pregunta es… hay alqo que podemos hacer con List<Animal> y que NO podamos hacer con List<Perro>? Veamos…

Con List<Animal> puedo contar cuantos animales hay. Con List<Perro> también.

Con List<Animal> puedo obtener todos los Animales que hay. Con List<Perro> puedo obtener los Perros, pero dado que Perro deriva de Animal, si obtengo un Perro estoy obteniendo un Animal (primer ejemplo que hemos visto). Así pues ningún problema.

Con List<Animal> puedo añadir un Animal. Con List<Perro> puedo añadir… un Perro. Ojo que eso es importante: A List<Animal> puedo añadirle cualquier Animal… puede ser un Perro, puede ser un Gato. A List<Perro> no puedo añadirle cualquier animal, debe ser un Perro forzosamente.

Por lo tanto ya hemos encontrado que se puede hacer con List<Animal> que no pueda hacerse con List<Perro>: Añadir un Gato.

Si C# nos dejara aplicar covarianza entonces eso sería válido:

List<Animal> animales = new List<Perro>();
animales.Add(new Gato());       // EEehhh... estoy añadiendo un Gato a una lista de Perros?

Por lo tanto, para evitar eso y asegurar que las listas de perros sólo tendrán perros el compilador no nos deja hacer esa conversión: Los genéricos no son covariantes.

Y los arrays? Recordáis que los arrays sí son covariantes. El siguiente código es válido y legal:

Animal[] animal = new Perro[100];
animal[0] = new Gato(); // Un Gato en una jauría de Perros!

Si ejecutas el siguiente código obtendrás una ArrayTypeMismatchException en tiempo de ejecución. Es decir el código compila pero luego rebienta.

Alguien podría decir que hubiesen aplicado eso mismo a las Listas… dejar que fuesen covariantes y luego rebentar en tiempo de ejecución si añado un Gato a una List<Perro>. Porque no lo han hecho así? Pues porque repetir errores no es nunca una buena solución. Los arrays jamás debieron haber sido covariantes. Si los crearon así fue para dar soporte a lenguajes tipo Java dentro del CLR (Java tiene arrays covariantes). Y así estamos: un error de diseño de Java propagado a .NET. Fijaos que eso obliga a que cada vez que añadimos un elemento en un array el CLR en tiempo de ejecución deba comprobar que el elemento realmente es del tipo del array. Viva la eficiencia!

Y con todo eso… llegó el Framework 4

Bien… Ahora analicemos el siguiente código:

static IEnumerable<Perro> JauriaDePerros()
{
    return new List<Perro>();
}
static void Main(string[] args)
{
    IEnumerable<Animal> perritos = JauriaDePerros();
}

Ya os lo avanzo: el siguiente código no compila con el Framework 3.5. Recordad: los genéricos no son covariantes y hemos visto la razón. Pero tiene sentido en este caso? Hay algo que pueda hacer con un IEnumerable<Animal> y que no pueda hacer con IEnumerable<Perro>? Veamos…

Con un IEnumerable<Animal> puedo obtener todos los Animales. Con un IEnumerable<Perro> puedo obtener todos los Perros, pero como hemos visto ya, los Perros los puedo ver como Animales.

Y ya está. No puedo hacer nada más con un IEnumerable<> salvo obtener sus elementos. Entonces porque no compila el código en C#? Pues bien, porque pagan justos por pecadores: En el framework 3.5 los genéricos no son covariantes. Nunca, aunque por lógica pudiesen serlo.

Para tener una solución a estos casos donde la covarianza tiene sentido, debemos usar el Framework 4 (VS2010). Una de las novedades que incorpora C# en esta versión es precisamente esta: covarianza de genéricos en según que casos.

Veamos: la covarianza en genéricos es segura cuando el parámetro genérico se usa sólamente de salida. Es decir cuando ningún método acepta ningún parámetro del tipo genérico, como mucho sólo lo devuelven. El problema en el caso de List<> estaba en que podía añadir un Gato a una lista de Perros. Y eso es posible porque uno de los métodos de la clase List<T> es Add(T item). Es decir el tipo genérico se usa como valor de entrada a los métodos. En cambio con IEnumerable<T> hemos visto que no hay ningún problema: En un IEnumerable<T> sólo puedo obtener sus elementos, pero no puedo añadirle elementos nuevos. No hay ningún método que reciba un parámetro del tipo genérico. Como mucho hay métodos que devuelven ojetos del tipo genérico. En este caso la covarianza es segura.

Para indicar en C# 4.0 que una clase genérica es covariante respecto a su tipo genérico, usamos la palabra clave out. P.ej. IEnumerable<T> en C# 4.0 está definido como:

public interface IEnumerable<out T> : IEnumerable
{
    // Métodos...
}

Fijaos en el uso de out para indicarle al compilador: Este tipo es covariante respecto al tipo genérico T. Entonces este código que en VS2008 no compilaba, es válido en C# 4.0:

static IEnumerable<Perro> JauriaDePerros()
{
    return new List<Perro>();
}
static void Main(string[] args)
{
    IEnumerable<Animal> perritos = JauriaDePerros();
}

Por supuesto, esto sigue sin compilar:

static List<Perro> JauriaDePerros()
{
    return new List<Perro>();
}
static void Main(string[] args)
{
    List<Animal> perritos = JauriaDePerros();
}

Ya que List<T> no es covariante respecto al tipo genérico T (lógico, si lo fuese podría añadir un Gato a una lista de Perros).

En cambio eso si que es correcto en VS2010:

static List<Perro> JauriaDePerros()
{
    return new List<Perro>();
}
static void Main(string[] args)
{
    IEnumerable<Animal> perritos = JauriaDePerros();
}

Aunque el método JauriaDePerros() devuelve una List<Perro>, el código funciona porque:

List<T> implementa IEnumerable<T>

IEnumerable<T> es covariante respecto a T

En el fondo, fijaos que no hay problema: con perritos lo único que puede hacerse es obtener sus elementos, así que de nuevo no hay peligro de que añada un Gato a perritos.

Declaración de mis clases genéricas covariantes

Si yo creo una clase que quiera que sea covariante con su tipo genérico, simplemente debo usar out. La única restricción es que ningún método de mi clase podrá aceptar un parámetro del tipo genérico:

interface Foo<out T>
{
    T Bar() { ... }
    void Baz(T t) { ... }
}

Este código no compila (error CS1961: Invalid variance: The type parameter 'T' must be contravariantly valid on 'ConsoleApplication5.Foo<T>.Baz(T)'. 'T' is covariant.). Ese mensaje de error largote lo único que quiere decir es que T es covariante, y por lo tanto no podemos aceptar parámetros de tipo T.

Finalmente tened presente que sólo las interfaces pueden declarar que su tipo genérico es covariante (las clases no).

Bueno… dejémoslo aquí. Hay otro termino ligado a la covarianza que es la contravarianza, aunque no es tan común como la covarianza y quizá algún día hablemos de ella :)

Un saludo y recordaros lo que digo siempre en los posts de esta serie: Si tenéis temas sobre el lenguaje C# que queráis tratar, hacédmelo saber y haré lo que pueda!!!

PD: Para variar, eso es un crosspost desde mi blog en geeks.ms! Pásate por allí que somos más!

Saca tus scripts de tu código HTML

2010-11-12T12:44:00.001+01:00

Buenas! En el post anterior os comenté el soporte de Unobtrusive Ajax en ASP.NET MVC3. Hoy quiero mostraros que esa técnica ni es exclusiva de MVC3, ni requiere HTML5 para nada. En fin, que podéis empezar a usarla ya, con independencia de la tecnología que uséis. Lo que contaré en este artículo no es nada “revolucionario” ni una “técnica nueva”…

De hecho, el ejemplo va a ser una página HTML, nada de ASP.NET :)

Veamos, la técnica de Unobtrusive Javascript, se refiere a no tener mezclado código javascript con código de marcado HTML. Es decir, no queremos algo como:

<input type="text" id="txtName" onkeypress="checkKey();" />

Aquí estamos mezclando código HTML con el código javascript (la llamada checkKey en el onkeypress).

Imaginemos que queremos que nuestros textboxes sólo acepten números. Y recordad que el objetivo es no tener código javascript mezclado con nuestro código HTML.

Eso lo podemos conseguir fácilmente, ya con jQuery:

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <title>Demo Unobtrusive Javascript</title>
    <script src="jquery-1.4.1.js" type="text/javascript"></script>
</head>
<body>
    <script type="text/javascript">
        $(document).ready(function () {
            $('input:text').keypress(function (event) {
                if (event.keyCode < 47 || event.keyCode > 58) {
                    event.preventDefault();
                }
            });
        });
    </script>

    Introduce sólo números: <br />
    <input type="text" />
</body>
</html>

Incluso, si no queréis que haya el tag <script> con todo el código, podemos moverlo a un .js separado y usarlo desde nuestra página HTML que entonces quedaría como:

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <title>Demo Unobtrusive Javascript</title>
    <script src="jquery-1.4.1.js" type="text/javascript"></script>
    <script src="myscript.js" type="text/javascript"></script>
</head>
<body>
    Introduce sólo números: <br />
    <input type="text" />
</body>
</html>

Por lo tanto vemos que con jQuery es muy fácil asignar comportamiento a objetos DOM, sin necesidad de andar con los handlers onXXXX.

Ahora bien, el código jQuery selecciona todos los <input type=”text”>, que passa si sólo quiero seleccionar algunos? Como le indico a mi código jQuery que sólo algunos textboxes son numéricos?

Una solución es invertarnos un atributo que indique que elementos queremos como numéricos. De esta manera p.ej. la página HTML queda como:

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <title>Demo Unobtrusive Javascript</title>
    <script src="jquery-1.4.1.js" type="text/javascript"></script>
    <script src="myscript.js" type="text/javascript"></script>
</head>
<body>
    Introduce sólo números: <br />
    <input type="text" datatype="numeric" />  <br />
    Aquí puedes introducir lo que quieras: <br />
    <input type="text" />
</body>
</html>

Fijaos en el “datatype=”numeric” que es el atributo que me va a servir para decidir que textboxes son numéricos.

Y el código de myscript.js queda como:

$(document).ready(function () {
    $('input[datatype=numeric]').keypress(function (event) {
        if (event.keyCode < 47 || event.keyCode > 58) {
            event.preventDefault();
        }
    });
});

Y listos, simplemente incluyendo “myscript.js” en cualquier página ya podemos declarar que un textbox es numérico simplemente poniendo el atributo datatype=”numeric”.

Ahora, si alguien hace otra librería javascript para textboxes numéricos si también usa este atributo para indicarlos (ahí está el quid de la cuestión) simplemente cambiando el <script> para que en lugar de ir a myscript.js vaya a la nueva librería, ya tengo todo el cambio hecho… es decir, me he independizado del framework javascript que use.

Y por ahí por donde entra HTML5? Pues bien, como eso de crearnos nuestros propios atributos está bien pero genera HTML que podríamos llamar inválido (en el sentido de que estos atributos no forman parte de HTML), para HTML5 han decidido simplemente que todos estos atributos “inventados” empiecen por data-.

Lo “único” que dice al respecto HTML5 es: “Hey, si tienes que invertarte un atributo para lo que sea, haz que su nombre empiece por data-. Todos los atributos que empiecen por data- son atributos inventados por alquien y deben ser ignorados a todos los efectos (salvo para quien lo haya inventado que hará con él lo que le plazca, claro). Ok, también añade una API específica (element.dataset) para leer esos atributos (pero eso de momento no nos importa ya que no está soportada por la mayoría de navegadores).

Por lo tanto, si en lugar de que mi atributo se llame datatype, hago que le llame data-datatype (p.ej. cualquier nombre que empiece por data-) ya lo tengo todo HTML5 compliant!

De hecho podéis hacer la prueba en http://validator.w3.org/check. Entráis el código HTML de la página y lo validáis contra:

HTML5 usando el atributo datatype=”numeric” y os dará error (Attribute not allowed)

HTML5 usando el atributo data-datatype=”numeric” y os validará correctamente.

Cualquier otra versión de HTML y os dará error en ambos casos.

Y listos! Por lo tanto fijaos que desde ya podeis empezar a aplicar técnicas de “Unobtrusive Javascript”: no necesitáis HTML5 para nada, ni MVC3 ni nada y la recompensa es un HTML mucho más claro y sencillo de ver!

Mi opinión es que, gracias a que HTML5 ha definido un espacio de nombres (data-) para los atrbutos inventados empezaremos a ver, cada ves más, librerías de javascript que usarán esos atributos, y seguramente algunos de ellos terminarán siendo estándares de facto (si yo hago una librería de javascript para validación. pues intentaré usar los mismos atributos data- que use la librería que sea líder en aquel momento, para compatibilizarme con ella).

Por cierto, si vais a usar muchos atributos data- en vuestras páginas web, echadle un vistazo a este plugin de jQuery: HTML5 Dataset.

Un saludo!

Nota: El código de ese artículo lo he probado con IE9 y Firefox 3.6.10.

PD: Esto es un crosspost de mi blog en geeks.ms (como no…)

Unobtrusive Ajax en MVC3

2010-11-09T11:56:00.001+01:00

Buenas! Una de las novedades más interesantes de MVC3 es el soporte para eso que se llama Unobtrusive Ajax. La verdad es que no encuentro una buena traducción para Unobtrusive (discreto no me convence).

La idea del Unobtrusive Ajax es evitar mezclar código script con código HTML. De la misma manera que CSS nos permite separar completamente el código HTML de su representación, con Unobtrusive Ajax vamos a poder separar el código javascript del código HTML.

Pero mejor, veamoslo con un ejemplo, ultra sencillo :)

Imaginad que tengo una vista con este contenido:

<h2>Normal Ajax</h2>
<% using (Ajax.BeginForm("PostData", new AjaxOptions() { HttpMethod="Post", UpdateTargetId="datadiv"})) { %>

    <label for="name">Name: </label>
    <input type="text" name="name" id="name"/>
    <input type="submit" value="Send" />
<% } %>
<hr />
Aquí irá el resultado: <p />
<div id="datadiv">
</div>

Esta vista genera un <form> con un campo de texto y envía los datos a una acción llamada “PostData” e incrusta el resultado de dicha acción (que será una vista parcial) en el div cuyo id es “datadiv”.

Este es el código HTML generado por esta vista en MVC2:

<h2>Normal Ajax</h2>
<form action="/Home/PostData" method="post" 
   onclick="Sys.Mvc.AsyncForm.handleClick(this, new Sys.UI.DomEvent(event));" 
   onsubmit="Sys.Mvc.AsyncForm.handleSubmit(this, new Sys.UI.DomEvent(event), { insertionMode: Sys.Mvc.InsertionMode.replace, httpMethod: &#39;Post&#39;, updateTargetId: &#39;datadiv&#39; });">
    <label for="name">Name: </label>
    <input type="text" name="name" id="name"/>
    <input type="submit" value="Send" />
</form>
<hr />
Aquí irá el resultado: <p />
<div id="datadiv">
</div>

Fijaos en que en el tag <form> se le ha incrustado código javascript para gestionar el onclick y el onsubmit (para poder realizar el envío via ajax).

Bien… y esta misma vista (idéntica) que código genera en MVC3? Pues el siguiente:

<h2>Normal Ajax</h2>
<form action="/Home/PostData" 
   data-ajax="true" data-ajax-method="Post" data-ajax-mode="replace" 
   data-ajax-update="#datadiv" method="post">

    <label for="name">Name: </label>
    <input type="text" name="name" id="name"/>
    <input type="submit" value="Send" />
</form>

<hr />
Aquí irá el resultado: <p />
<div id="datadiv">
</div>

Fijaos que diferencia… No hay nada de javascript mezclado en el código. Todo es HTML. Simplemente al tag <form> se le añaden unos cuantos atributos (los que empiezan por data-ajax) que indican como se debe comportarse este formulario a nivel de Ajax.

Y quien realiza “la magia”? Pues quien va a ser… nuestra amada jQuery, junto con una extensión de Microsoft (el fichero jquery.unobtrusive-ajax.js)! Para que esto funciona teneis que añadir tanto jQuery como la extensión de MS (yo los pongo en la master):

<script src="<%: Url.Content("~/Scripts/jquery-1.4.1.js") %>" type="text/javascript"></script>
<script src="<%: Url.Content("~/Scripts/jquery.unobtrusive-ajax.js") %>" type="text/javascript"></script>

Esta adaptación de los helpers en MVC3 para soportar esta característica es a lo que nos referimos cuando decimos que “ASP.NET MVC3 da soporte para Unobtrusive Ajax”, y es una doble gran noticia. Digo doble porque por un lado nos permite seguir usando los helpers con la garantía de que vamos a generar código “limpio” de javascript y por otro lado el helper de Ajax usa ¡por fin! jQuery. A diferencia de MVC2 donde el Helper Ajax usaba la Ajax Library de Microsoft. De hecho, aunque en los templates de proyecto se sigue poniendo, si me aceptas un consejo: bórrala y no la uses. Puedes borrarla con total tranquilidad porque en MVC3 ningún helper la usa.

Unobtrusive Ajax viene habilitado por defecto en los nuevos proyectos MVC3 pero lo podéis deshabilitar (y entonces generar el mismo código que en MVC2, usando la Microsoft Ajax Library). Podeis deshabilitarlo a nivel de vista o para todo el proyecto.

Para deshabilitarlo a nivel de vista, basta con incluir:

<% HtmlHelper.UnobtrusiveJavaScriptEnabled = false; %>

Para deshabilitarlo para todo el proyecto, puedes incluir ese mismo código en el global.asax.cs o bien usar web.config:

<configuration>
   <appSettings>
      <add key="UnobtrusiveJavaScriptEnabled" value="false"/>
   </appSettings>
</configuration>

Lo mismo para habilitarlo. Si no aparece la entrada UnobtrusiveJavaScriptEnabled en el <appSettings> el valor por defecto es false. Es por eso que si haces un upgrade de un proyecto de MVC2 a MVC3, no tendrás esta entrada en el web.config y por eso Unobtrusive Ajax estará deshabilitado!

Un saludo!

PD: El hecho de que los atributos que se usan para que Unobtrusive Ajax funcione empiecen por “data-“ es porque HTML5 reserva estos atributos “para usos propios de los scripts del site”, tal y como podéis leer en la especificación de Custom Data Attributes.

PD2: Para variar… otro crosspost desde mi blog en geeks.ms! ;-)

How to: Obtener controles de un formulario con generics II (Linq al rescate).

2010-11-08T11:29:00.001+01:00

Ayer Lluis escribía este gran post: How to: Obtener controles de un formulario con generics. Como bien dice es una pregunta… recurrente en todos los sitios :)

Lo bueno de eso del desarrollo es que para todo hay varias soluciones, así que aquí os propongo otra, pero usando Linq. Personalmente me encanta Linq, supongo que es porqué siempre me han fascinado los lenguajes funcionales…

Antes que nada tenemos que solucionar un temilla: Linq funciona sobre IEnumerable<T> pero la propiedad Controls de un Control devuelve un objeto de tipo ControlCollection (otra de esas n-mil clases que no tienen sentido alguno y que existen sólo porque no teníamos generics en la versión 1 del framework). Así que el primer paso es obtener un IEnumerable<Control> a partir de una ControlCollection. Con un método extensor eso es trivial:

public static IEnumerable<Control> AsEnumerable (this Control.ControlCollection @this)
{
    foreach (var control in @this) yield return (Control)control;
}

Ale… listos, con eso transformamos la CollectionControl en un IEnumerable<Control> y tenemos acceso a todo el potencial de Linq… Y como queda el método para obtener todos los controles de un tipo? Pues así:

public static IEnumerable<T> GetAllControls<T>(this Control @this) where T : Control
{
    return @this.Controls.AsEnumerable().Where(x => x.GetType() == typeof(T)).
        Select(y=>(T)y).
        Union(@this.Controls.AsEnumerable().SelectMany(x => GetAllControls<T>(x)).
        Select(y=>(T)y));
}

¡No me diréis que no es precioso: no hay bucles, no hay ifs… Os he dicho que me encanta Linq? ;-)

Hay una pequeña diferencia entre la versión de Lluís y esta mía: la versión de Lluís usa una List<Control> en la que añade todas las referencias (copia las referencias a la lista. Ojo: las referencias, no los controles). Esa versión que usa Linq, no copia las referencias en ningún sitio, sinó que simplemente itera sobre la coleccion original: no crea listas internas, ni nada… Ese es el poder de Linq!

Es cierto que al usar IEnumerable<T> como valor de retorno, perdemos el método ForEach() (puesto que IEnumerable<T> no lo tiene y Linq no lo proporciona), pero hacer un método ForEach es trivial:

public static void ForEach<T>(this IEnumerable<T> @this, Action<T> action)
{
    foreach (T t in @this)
    {
        action(t);
    }
}

De todos modos, si os preguntáis porque Linq no ofrece un método ForEach quizá deberíais leeros este post de Octavio: Observaciones con respecto a un método extensor ForEach<T>.

Un saludo a todos y gracias a Lluís por darme “la excusa” de hacer otro post! ;-)

PD: Eso es (como no) un crosspost desde mi blog de geeks.ms.

Opinión: De si Silverlight está muerto, agonizante o mejor que nunca

2010-11-03T10:54:00.001+01:00

Andamos todos revolucionados estos dias, a raíz de unas declaraciones de Bob Muglia donde decía “Our strategy with Silverlight has shifted”. Eso unido al énfasis que se dio a HTML5 en el keynote del PDC y la no mención en absoluto de nada referente a Silverlight han disparado los rumores.

Así pues… ¿está Silverlight muerto, agonizante o por el contrario está mejor que nunca? Primero un disclaimer: este es un post de opinión, todo lo que yo afirmo tajantemente en este post son cosas que yo creo. No tengo ni el conocimiento ni la razón absoluta, y además en MS nunca se sabe, así que como suele decirse: al final el tiempo dará y quitará razones :)

La estrategia inicial de Microsoft para posicionar Silverlight fue darle el nicho de aplicaciones web: Con Silverlight tus aplicaciones web tendrán una experiencia de usuario mejor, decían. En estos tiempos, comparar Silverlight con Flash era habitual, aunque Microsoft insistía en que no eran comparables: que Silverlight era para aplicaciones completas y no para pequeños adornos. Cuando hacía tiempo que Flash había asumido que no sustituiría a HTML, parecía ser que Silverlight quería asumir el relevo.

Pero con Silverlight 3 todo cambió: la posibilidad de ejecutar aplicaciones out-of-browser, la interoperabilidad COM y mejoras en el acceso a dispositivos locales, convertían a SL3 en algo distinto. Estaba claro que Silverlight llegaba a sitios donde HTML no sueña con llegar nunca. La batalla que inicialmente se libraba en el navegador ahora se trasladaba también al escritorio, y el rival era Adobe AIR. Habéis visto Seesmic Desktop 2? Es un excelente cliente de Twitter, para Windows y Mac, es una aplicación de escritorio… y está hecha con Silverlight.

¿Y donde estamos ahora?

El otro día en twitter conversaba con Alejandro Mezcua (@byteabyte) y Dani Mora (@LoDani) sobre el futuro de Silverlight. Yo argumentaba que no creo ni mucho menos que Silverlight esté muerto. De hecho le veo un gran futuro a Silverlight en aplicaciones de escritorio y en aplicaciones para Windows Phone 7 (bueno, aquí depende de como le vaya a WP7, claro). Pero no le veo futuro para aplicaciones web. Quiere decir esto que Silverlight va a desaparecer del browser? No, tiene su nicho en sites específicos donde HTML no llega: p. ej. nada mejor que Silverlight para streaming de video. Sí, sí… HTML5 va a soportar vídeo, pero no soportará DRM ni bitrates variables. Si necesitas esto, necesitarás algo externo que te lo de, y ahí entra Silverlight. Pero para la creación de aplicaciones web, no lo veo, y diría que Microsoft tampoco :)

¿Y RIA? La clave de RIA es lo que significa la I. Dani me comentaba que para él, la I de RIA era “aquel entorno que el administrador de sistemas podía controlar”. Entonces no estamos hablando de internet… llamésmole intranet o alguna otra cosa, pero no internet. Si quieres desarrollar una aplicación para internet no hay mejor opción que HTML. Y los tiempos han cambiado mucho: de acuerdo que hace tiempo desarrollar con javascript era poco menos que un infierno, pero ahora tenemos a jQuery que convierte eso en un juego de niños. Antes Ajax era doloroso y entraba con vaselina: ahora con un par de líneas puedes usar Ajax sin preocuparte de que navegadores se usan ni nada parecido. Y sí: hay jQuery para dispositivos móviles. Aunque de todos modos la experiencia parece demostrar que en los móviles la gente prefiere aplicaciones nativas antes que webs.

Así que si quieres estar presente en aplicaciones web dentro de poco tiempo, aprende ya HTML5. No hagas caso de los que dicen que no está terminado, que no saldrá hasta dentro de no se cuantos años: son verdades a medias. Es cierto que la especificación no está lista, pero muchas partes ya estan terminadas, y ya están siendo implementadas en los navegadores. No ha salido hace poco la noticia de que IE9 era el navegador más compatible con HTML5? Como podría ser si no hubiese salido nada de HTML5? Dentro de poco ya comenzaremos a ver sites desarrollados en HTML5. El momento de lanzarse no es dentro de un, dos o tres años: es ahora.

Pero seguiremos viendo Silverlight en el navegador? Pues creo que sí: en la gran internet en aquellos sitios junto a HTML, donde se requieran aspectos que HTML5 no va asumir y en intranets (o entornos controlados) también supongo que podrán verse… Aunque en estos entornos, porque obligar al usuario a usar un navegador? Las capacidades out of browser de Silverlight hacen que el usuario tenga la sensación de usar una aplicación nativa, con toda la seguridad del sandbox de Silverlight y la misma facilidad de actualización que si una aplicación web se tratara.

Y fuera del navegador? Pues sin duda. Veremos cada vez más aplicaciones de escritorio desarrolladas en Silverlight, y tener todas sus ventajas: actualizaciones automáticas, seguridad y multiplataforma (Windows, Mac). Y ojalá Microsoft se lance en serio a Linux y haga su implementación de Silverlight (y no lo deje medio abandonado con Moonlight).

De hecho, para resumir este post, si hay alguien que deba sentirse amenazado por Silverlight no es ni mucho menos HTML5… en todo caso, si hemos de buscar a alguien, se trataría de WPF. Cada versión de Silverlight acorta distancias con su hermano mayor y no es descabellado pensar si algún dia llegarán a unirse.

Y a vosotros que os parece?

Un saludo!

PD: Como siempre… esto es un crosspost desde mi blog en geeks.ms.

ASP.NET MVC3 Beta: Mis impresiones

2010-10-07T14:28:00.001+02:00

Buenooo… ayer fue un día movidito en Microsoft: anunciaron de golpe la beta 2 de WebMatrix, la beta de MVC3 y un gestor de paquetes OSS para Visual Studio llamado NuPack. También he visto a través del Web PI que está la CTP2 de Compact SQL 4.

MVC1 salió con 5 (creo) previews antes de la beta, con MVC2 juraria que hicieron un par o tres, y con MVC3 sólo un preview1 y luego ya la beta… a ese ritmo MVC4 cuando salga lo hará ya con el SP1 incorporado. :P Esos de Microsoft van cada vez más rápido.

Bueno, aquí van un poco mis impresiones sobre la Beta 3 de MVC :)

Me centraré básicamente en lo que ha cambiado desde la preview1 hasta la Beta.

1. Creación de aplicaciones

Cuando le damos a nuevo proyecto en el Visual Studio, nos sale una sola opción de MVC3: ASP.NET MVC 3 Web Application y una vez la seleccionamos es cuando nos deja elegir si queremos una aplicación vacía o la estándard (con los controladores Account y Home) y que View Engine queremos usar. Son las mismas opciones que teníamos en MVC2 (excepto lo del view engine) pero mejor organizadas.

Pero vamos… nada nuevo bajo el sol :D

2. Donde está IServiceLocator?

En mi post sobre la preview1 comentaba que el soporte para IoC se basaba en la interfaz IServiceLocator, un proyecto de codeplex para proporcionar una interfaz común a distintos contenedores IoC y así permitir independizarnos de ellos. Decía también que la Preview1 contenía una implementación propia de IServiceLocator en lugar de usar la del assembly que está en codeplex, pero que se esperaba que en la versión final eso no fuera así.

Pues bien… al final eso ha cambiado un poco: Ahora, a través de la clase DependencyResolver podemos indicar a MVC3 que debe usar para resolver sus dependencias. Y tenemos tres posibilidades:

Pasarle un objeto que implemente una interfaz nueva llamada IDependencyResolver (propia de MVC3). Dicha interfaz está definida:

public interface IDependencyResolver
{
    object GetService(Type serviceType);
    IEnumerable<object> GetServices(Type serviceType);
}

Pasarle dos delegates, el primero del cual se corresponde al método GetService y el segundo al método GetServices

Pasarle un object. En este caso el object debe implementar la interfaz IServiceLocator. Pero (imagino que) ASP.NET MVC3 invocará los métodos via reflection, por lo que cualquier IServiceLocator vale, no es necesario usar el assembly de codeplex. Supongo que es para evitar tener una dependencia de MVC3 hacia un assembly “externo”.

Veamos un ejemplo:

P.ej. si usásemos Unity podríamos crear un IDependencyResolver propio:

public class UnityDependencyResolver : IDependencyResolver
{
    private IUnityContainer _ctr;

    public UnityDependencyResolver(IUnityContainer ctr)
    {
        _ctr = ctr;
    }

    public object GetService(Type serviceType)
    {
        return _ctr.Resolve(serviceType);
    }

    public IEnumerable<object> GetServices(Type serviceType)
    {
        return _ctr.ResolveAll(serviceType);
    }
}

Y registrarlo en el global.asax:

UnityContainer ctr = new UnityContainer();
DependencyResolver.SetResolver(new UnityDependencyResolver(ctr));

Guay! Pero también podríamos usar la versión que admite un object y pasarle una implementación de IServiceLocator. La versió 2.0 de Unity ya viene con el assembly del service locator incorporado y un adaptador creado (si usais versiones anteriores de Unity os podéis descargar tanto la implementación de IServiceLocator como el adaptador para Unity desde codeplex).

En nuestro caso nos basta con agregar una referencia al ensamblado Microsoft.Practices.ServiceLocation.dll (que viene con Unity o os habéis descargado de codeplex) y usar:

UnityContainer ctr = new UnityContainer();
DependencyResolver.SetResolver(new UnityServiceLocator(ctr));

(Si usáis una versión de Unity anterior a la 2.0 necesitaréis también una referencia a Microsoft.Practices.Unity.ServiceLocatorAdapter.dll que también os habréis descargado de codeplex).

Listos! Con esto MVC3 ya usará nuestro DependencyResolver para crear los controladores, así que ya podremos inyectarles dependencias (fijaos que no ha sido necesario crear una factoría propia como hacíamos en MVC2).

3. IControllerActivator

IControllerActivator es una interfaz nueva de MVC3 cuya responsabilidad es devolver una instancia de un controlador de un determinado tipo. Antes esa responsabilidad era una más de las responsabilidades de la factoría de controladores: cuando en MVC2 queríamos usar DI generalmente implementábamos una factoría propia derivada de DefaultControllerFactory y refefiniamos el método GetControllerInstance:

P.ej. esa sería una factoría de controladores para usar IServiceLocator en MVC2:

public class ServiceLocatorControllerFactory : DefaultControllerFactory
 {
     private readonly IServiceLocator _sl;
     public ServiceLocatorControllerFactory(IServiceLocator sl) 
     {
         _sl = sl;
     }
     protected override IController GetControllerInstance(RequestContext requestContext, Type controllerType)
     {
         IController controller = null;
         controller = _sl != null ?  _sl.GetInstance(controllerType) as IController : 
             base.GetControllerInstance(requestContext, controllerType);
         return controller;
     }
 }

En MVC3 han separado los dos comportamientos: Por un lado el decidir que tipo de controlador instanciar se queda en la factoría de controladores y por otro lado instanciar el controlador es responsabilidad de IControllerActivator.

El uso de IControllerActivator nos permite definir como se crean nuestros controladores. Si no hay ningún IControllerActivator MVC3 usará el DependencyResolver (así que no es necesario implementar IControllerActivator sólo para DI). Si no hay DependencyResolver pues supongo que usará Reflection.

Como MVC3 busca las cosas en varios sitios podemos pasarle el IControllerActivator a la DefaultControllerFactory (tiene un parámetro que acepta un IControllerActivator) o bien, registrarlo en el DependencyResolver. O sea podemos usar esto:

// Registramos un singleton con nuestro IControllerActivator
ctr.RegisterInstance<IControllerActivator>(new CustomControllerActivator());
DependencyResolver.SetResolver(new UnityServiceLocator(ctr));
// No registramos IControllerFactory por lo que se usará la DefaultControllerFactory

O bien esto:

// Registramos la DefaultControllerFactory como la factoría a usar
// pasándole el IControllerActivator deseado
ctr.RegisterInstance<IControllerFactory>
    (new DefaultControllerFactory(new CustomControllerActivator()));
DependencyResolver.SetResolver(new UnityServiceLocator(ctr));

Pero ambas cosas a la vez no (os dará error).

4. Nuevos Helpers

Bueno, ahora tenemos un conjunto de Helpers nuevos (bueno, nuevos para MVC, porque ya estaban en WebMatrix). Para usar esos helpers basta con agregar una referencia a System.Web.Helpers (viene ya por defecto):

<div>
    El Hash de eiximenis es: @Crypto.Hash("eiximenis")
</div>

Diria que no están disponibles todos los helpers que hay en WebMatrix… Espero que en la versión final sí estén todos, porque hay algunos que son una pasada!

5. Ajax no “obtrusivo” (unobtrusive)

El helper Ajax de MVC3 puede generar código Ajax que no está mezclado con el código HTML, aprovechando jQuery y una de las nuevas capacidades de HTML5… P.ej. el siguiente código en una vista:

@Ajax.ActionLink("Pulsa aquí para modif el DIV", "AjaxAction", new AjaxOptions() { UpdateTargetId="mydiv"})
<div id="mydiv">Div a modificar</div>

Nos genera el código HTML:

<a data-ajax="true" data-ajax-mode="replace" data-ajax-update="#mydiv" href="/Home/AjaxAction">Pulsa aqu&#237; para modif el DIV</a>
<div id="mydiv">Div a modificar</div>

Fijaos que hay atributos “data-ajax-*“ que son interpretados por jQuery para realizar las acciones: de esa manera no hay ninguna llamada a ningún script mezclado con el código. Los atributos que empiezan por “data-“ son considerados especiales en HTML5 (custom HTML5 attributes): HTML5 no admite que pongamos nuestros propios atributos a no ser que empiecen por data-. Esto permite separar el comportamiento (definiendolo en estos atributos especiales) del código.

6. Soporte para Razor

Pues… sigue bajo mínimos… Es decir, Razor está totalmente soportado en run-time (y ahora con sintaxis VB.NET también!) pero para VS2010 Razor sigue sin existir. Las vistas .cshtml (o .vbhtml) no tienen ni sintaxis coloreada ni tampoco intellisense. Pero es que ni tan siquiera las reconoce como HTML (o sea ni tenemos intellisense de HTML tampoco).

Al margen de esto hay algunas novedades menores para Razor como el soporte de @model para definir el modelo, pero vamos… nada excepcionalmente nuevo.

7. Conclusiones

Las dos grandes novedades de esta Beta, respecto a la preview1, son algunas mejoras más en la inyección de dependencias (DependencyResolver, IControllerActivator) y el soporte para ajax no “obtrusivo”. El resto son mejoras menores (aunque interesantes).

Sigo pensando que, del mismo modo que se llama MVC3 se podría llamar MVC2.5, porque no hay cambios espectacularmente grandes (excepto Razor, pero es simplemente otro ViewEngine, como muchos más que ya existían). Eso no es necesariamente malo: el framework ya está alcanzando cierto grado de madurez.

Para finalizar, leeros las release notes de la beta de MVC3 donde se enumeran las novedades!

Un saludo!

PD: Para variar… esto es un crosspost desde mi blog en geeks.ms!!!!

SQL Server Compact 4: Unable to load the native components

2010-10-06T12:08:00.001+02:00

Buenas! Un post ligerito, ligerito :)

Ando esos días probando cosillas con SQL Server Compact 4 (que os podéis descargar desde su página de descargas o bien usando Web Platofrm Installer).

Habiendo probado código con EF 4 Code First que estaba funcionando bien, empecé otras pruebas usando el proveedor propio de ADO.NET. Así que agregué una referencia a la System.Data.SqlServerCe.dll que viene con SQL Server Compact 4, y cree una conexión:

SqlCeConnection con = new SqlCeConnection()

Pues bien, al crear la conexión (fijaos que aquí no hay cadena de conexión, todavía no me conecto a ningún .sdf) ya me salta una SqlCeException:

Unable to load the native components of SQL Server Compact corresponding to the ADO.NET provider of version 8402. Install the correct version of SQL Server Compact. Refer to KB article 974247 for more details.

Hombre, es de agradecer que la propia excepción te diga un KB que consultar, así que ni corto ni perezoso me dirigo al KB974247, pero nada de lo que dice es aplicable en mi caso.

Descartando el hecho de que sea una mala instalación (puesto que con EF 4 Code First era capaz de conectarme) me puse a mirar que podría estar pasando… y la respuesta final es que se deben copiar los binarios de SQL Server Compact 4 a la carpeta bin de la aplicación.

En mi caso SQL Server Compact 4 se ha instalado en C:\Program Files\Microsoft SQL Server Compact Edition\v4.0 y los binarios que he copiado son las carpetas x86 y amd64 que están en la carpeta Private. De hecho en mi caso me basta con la carpeta x86 puesto que mi máquina es de 32 bits.

Así pues en el bin/Debug de mi aplicación tengo mi aplicación, la System.Data.SqlServerCe.dll y la carpeta x86 con los binarios de SQL Server Compact 4.

Y entonces me funciona todo correctamente.

Un saludo!

PD: Y de regalo, os dejo (por si no lo conocíais) el enlace de una extensión, llamada SqlCeToolbox, para vs2010 para poder tratar con ficheros .sdf de la versión 4 (sinó la otra manera que hay es usar WebMatrix que tiene un diseñador de tablas, pero me parece más potente esta exensión).

PD2: Y para variar… esto es un crosspsost desde mi blog en geeks.ms!! ;-)

EF4 Code First, MVC2 y Unity para atarlo todo un poco…

2010-09-24T13:00:00.001+02:00

Buenas! No soy ni mucho menos un experto en EF (es más, me acabo de poner), como pueda serlo p.ej. Unai, pero desde que Scott Guthrie publicó un post sobre EF Code First he empezado a mirar algunas cosillas.

Resumiendo rápidamente EF Code First nos permite desarrollar nuestra capa de acceso a datos codificando primero las clases, clases que son POCO. Eso nos permite conseguir lo que se conoce como persistance ignorance (o que las clases que nos representan los datos sean agnósticas sobre cualquier tecnología de acceso a datos).

Que quede claro que Code First no es la única manera de usar objetos POCO en EF: Unai y Alberto hablan del tema aquí y aquí. Y dad por seguro que ellos conocen EF mucho más que yo :)

Lo que os quiero comentar es como se puede montar EF Code First en una aplicación MVC2 para poder usar el patrón Repository y Unit Of Work, de forma que los controladores no deban saber nada del mecanismo subyacente de acceso a datos (es decir, los controladores ignoran completamente que están usando EF).

1. Rápida, rapidísima introducción a EF Code First

Usar EF Code First es muy sencillo. En el post de Scott Guthrie está todo explicado paso a paso, pero resumiendo podríamos decir que me puedo crear una clase tal que:

public class Persona
{
   public int PersonaId {get; set;}
   public string Nombre {get; set;}
}

Esta clase nos permitiría acceder a datos almacenados en una tabla con los campos PersonaId y Nombre (EF Code First es capaz de crear la BBDD a partir del modelo de objetos). Para acceder a la bbdd creamos un objeto derivado de DbContext:

public class MyDatabase : DbContext
{
   public DbSet<Persona> Personas {get; set;}
}

Y a partir de aquí instanciamos un objeto MyDatabase y lanzamos consultas linq contra la propiedad Personas… :)

2. Patrón repositorio y Unit of work

Esos patrones están explicados por activa y por pasiva en muchos sitios. P.ej. aquí está el patrón repositorio y aquí el Unit of Work (UoW). Básicamente entendemos que el repositorio es una colección de objetos en memoria y que el patrón UoW sincroniza todos los cambios hechos en memoria hacia la base de datos.

Supongamos estos dos interfaces para definir ambos patrones:

public interface IRepository<TEntity> where TEntity : class
{
    IQueryable<TEntity> AsQueryable();    
    IEnumerable<TEntity> GetAll();
    IEnumerable<TEntity> Find(Expression<Func<TEntity, bool>> where);
}

public interface IUnitOfWork
{
    void Commit();
}

Mi repositorio es de sólo lectura (no hay métodos Add ni Remove ni nada, pero todo es añadirlos) y el Unit of Work lo único que tiene es el método Commit() para sincronizar los cambios hechos en los repositorios y mandarlos todos a la base de datos.

EF Code First, implementa de per se el patrón Unit Of Work (a través de DbContext) y también el patrón repositorio a través de DbSet<>, pero recordad que yo quiero “agnostizarme” al respecto de EF, por eso creo las interfaces y ahora debo crear implementaciones de ellas para EF:

public class Repository<TEntity> : IRepository<TEntity> where TEntity : class
{
    private IDbSet<TEntity> _dbSet;

    public Repository(IDbContext objectContext)
    {
        _dbSet = objectContext.Set<TEntity>();
    }
    public IQueryable<TEntity> AsQueryable()
    {
        return _dbSet;
    }
    public IEnumerable<TEntity> GetAll()
    {
        return _dbSet.ToList();
    }
    public IEnumerable<TEntity> Find(Expression<Func<TEntity, bool>> where)
    {
        return _dbSet.Where(where);
    }
}

public class UnitOfWork : IUnitOfWork, IDisposable
{
    private readonly IDbContext _objectContext;
    
    public UnitOfWork(IDbContext objectContext)
    {
        _objectContext = objectContext;
    }

    public void Dispose()
    {
        if (_objectContext != null)
        {
            _objectContext.Dispose();
        }
        GC.SuppressFinalize(this);
    }

    public void Commit()
    {
        _objectContext.SaveChanges();
    }
}

La única “complicación” es en la implementación de UnitOfWork, que en el constructor uso un objeto de tipo IDbContext, pero esta interfaz no existe en EF: me la he inventado yo, para poder realizar DI luego cuando use Unity. La interfaz IDbContext es muy simple:

public interface IDbContext : IDisposable
{
    IDbSet<T> Set<T>() where T : class;
    int SaveChanges();
}

Me permite obtener un IDbSet de entidades de tipo T y el método SaveChanges para persistir los cambios realizados en este contexto hacia la BBDD.

3. Uso de todo esto…

Para usar directamente un repositorio me basta con instanciarlo, pasándole como parámetro el IDbContext. Pero recordad que la clase DbContext de EF Code First no implementa IDbContext (que me lo he inventado yo), así que uso el patrón Adapter para traducir los objetos DbContext a IDbContext:

public class DbContextAdapter : IDbContext
{
    private readonly DbContext _context;
    public DbContextAdapter(DbContext context)
    {
        _context = context;
    }
    public void Dispose()
    {
        _context.Dispose();
    }
    public IDbSet<T> Set<T>() where T : class
    {
        return _context.Set<T>();
    }
    public int SaveChanges()
    {
        return _context.SaveChanges();
    }
}

Ahora sí que ya puedo crear un repositorio:

IDbContext ctx = new DbContextAdapter(MyDatabase);  // MyDatabase deriva de DbContext
var rep = new Repository<Persona>(ctx);
var personas = rep.FindAll();

Para usar el Unit of Work vinculado a un contexto haríamos lo mismo.

4. Añadiendo IoC a todo esto…

Ahora que ya vemos como podemos usar nuestro repositorio, vamos a ver como Unity nos ayuda a tener IoC y independizarnos realmente de EF.

Primero podríamos registrar las implementaciones concretas de IRepository y IUnitOfWork:

// Container es el IUnityContainer
Container.RegisterType(typeof(IRepository<>), typeof(Repository<>));
Container.RegisterType<IUnitOfWork, UnitOfWork>();

Ahora debemos mapear IDbContext a DbContextAdapter (porque para instanciar tanto IRepository como IUnitOfWork les debemos pasar un IDbContext. Podríamos usar lo siguiente:

Container.RegisterType<IDbContext, DbContextAdapter>();

Este RegisterType está bien, pero el problema nos viene cuando vemos que el constructor de DbContextAdapter tiene un objeto DbContext. Eso significaría que Unity nos crearía un objeto de la clase DbContext y no de la clase derivada MyDatabase, para instanciar los objetos DbContextAdapter. Nota: Una solución sería que la clase DbContextAdapter tuviese en su constructor un objeto que no fuera DbContext sinó MyDatabase pero eso entonces limita la reutilización de todo lo que estamos haciendo!

Por suerte no estamos perdidos! Unity incorpora un mecanismo mediante el cual le podemos decir como crear un objeto de una determinada clase. En mi post sobre Unity 2.0, hablé de las Injection Factories. La idea es decirle a Unity que cuando necesite un objeto de la clase indicada, en lugar de crearlo tal cual use una factoría nuestra.

Es decir podemos hacer una factoría para crear DbContext que en lugar de un DbContext devuelva un MyDatabase, y Unity usará dicha factoría cada vez que deba crear un DbContext:

Container.RegisterType<DbContext>(new InjectionFactory(x => new MyDatabase()));

Listos! Con esto cuando Unity deba pasar a DbContextAdapter un objeto DbContext (como indica el constructor) creará realmente un objeto MyDatabase.

Ahora si que ya puedo hacer:

var rep = Container.Resolve<IRepository<Persona>>();

5. Y finalmente… MVC2

Para integrar esto dentro de MVC2 es muy sencillo: como siempre que queramos inyectar IoC en los controladores lo que debemos tocar es… la factoría de controladores:

public class UnityControllerFactory : DefaultControllerFactory
{
    private readonly IUnityContainer _sl;

    public UnityControllerFactory(IUnityContainer sl) 
    {
        _sl = sl;
    }

    protected override IController GetControllerInstance(RequestContext requestContext, Type controllerType)
    {
        IController controller = _sl.Resolve(controllerType);
        return controller;
    }
}

Y como siempre establecerla en el Global.asax:

UnityControllerFactory slcf = new UnityControllerFactory(container);
ControllerBuilder.Current.SetControllerFactory(slcf);

Y listos! Ahora si que hemos llegado al punto final. Por fin podemos declarar un controlador tal que:

public class PersonasController : Controller
{
    private IRepository<Persona> _rep;
 
    public HandController(IRepository<Persona> rep)
    {
        _rep = rep;
    }
}

Y empezar a trabajar usando el repositorio! :)

Fijaos que en este punto (el controlador) no tenemos nada que nos ate a EF: el repositorio es una interfaz y las clases que usa el repositorio son objetos POCO.

6. Y para terminar (pero NO lo menos importante)…

Cuando trabajamos con aplicaciones web, es recomendable que los contextos de base de datos tengan una duración (lifetime) de request (se les llama objetos per-request): es decir si durante una misma petición se necesitan dos repostorios, estos dos repositorios deben de compartir del contexto de base de datos. Con lo que tenemos ahora no sucede esto, ya que cada vez que Unity deba crear un Repository<> creará su DbContextAdapter asociado que a su vez creará un DbContext (MyDatabase) nuevo. Ese comportamiento no es el desado.

Por suerte Unity tiene un mecanismo muy bueno para poder establecer cada cuando debe el contenedor crear un objeto de un tipo determinado: los lifetime managers. Una solución es crearse un HttpRequestLifetimeManager, de forma que los objetos sólo persistirán durante la misma petición y usar este lifetime manager cuando hagamos el RegisterType de DbContext.

En http://unity.codeplex.com/Thread/View.aspx?ThreadId=38588 tenéis una implementación de un HttpRequestLifetimeManager, junto con una interesante aportación sobre el uso (en su lugar) de contenedores hijos que mueran a cada request, que tengan los objetos registrados como singletons y eliminar el contenedor hijo (con Dispose()) al final de cada request. Esto tiene la ventaja de que se llamaría a Dispose() de los objetos contenidos (en esta segunda aproximación es el contendor hijo el que tiene un ciclo de vida per-request).

7. Referencias

Los siguientes posts contienen más información al respecto:

Entity Framework POCO (EF4): Generic Repository and Unit of Work Prototype. Este es el post que me ha servido de inspiración y de ayuda. Tiene una continuación (Unity Extension for Entity Framework POCO Configuration, Repository and Unit of Work) donde comenta el uso de Unity. Estos dos posts son de lectura imprescindible, aunque por un lado haya tenido que modificar algunas cosillas para que funcione con la CTP4 de EF Code first y por otro en el tercer post utilize una StaticFactoryExtension en lugar de una Injection Factory (supongo que usa Unity 1.2 que no soporta Injection Factories). Este tercer post utiliza una aproximación genial que es el uso de una extensión de Unity para configurar todos los mappings para los objetos de EF. Repito: lectura imprescindible.

Los posts de Scott Guthrie sobre EF Code First:

Un saludo!!! :)

PD: Como no… esto es un crosspost desde mi blog en geeks.ms

ASP.NET MVC – Formato de salida según Content-Type

2010-09-10T13:07:00.001+02:00

El otro día escribí un post donde vimos como mostrar una vista en PDF o HTML en función de una URL del tipo /controlador/accion(formato)/parámetros. El post estaba centrado básicamente en la tabla de rutas y cómo la URL clásica de ASP.NET MVC /Controlador/Accion/Parámetros no es una obligación sinó básicamente una convención.

Hadi Hariri realizó un comentario, muy interesante a mi jucio. Venía a decir que antes que añadir en la ruta el parámetro formato es mejor usar el campo Accept de la request. Copio literalmente: “La tercera opcion, que lo hace más transparente al usuario y además está en acorde a ReST, es la de usar las el ContentType en la petición, que es lo que yo normalmente hago.”

Si quieres exponer una API lo más ReST posible en ASP.NET MVC y que tenga salidas en distintos formatos, sin duda deberías tener en cuenta la sugerencia de Hadi.

1. La cabecera de la petición http

Cuando un cliente envía una petición http a un servidor, que contiene una cabecera con varios parámetros. Dicha cabecera tiene varios campos que permiten especificar determinadas opciones que el cliente desea. Uno de esos campos es el campo Accept que permite indicar que formatos de respuesta acepta el cliente y en que orden.

P.ej. si hago una petición con Firefox a http://www.google.es, el contenido del campo Accept de la cabecera que firefox envia es (lo acabo de mirar con Firebug):

text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Que podríamos interpretar (más o menos) como: Mis formatos preferidos son text/html y application/xhtml+xml, si no puedes en ninguno de esos dos, envíamelo en application/xml y si no puedes, pues me tragaré lo que me mandes.

El valor exacto de dicha cabecera depende del browser… P.ej. IE8 para la misma peticion envia el siguiente valor en Accept (lo acabo de mirar con Fiddler):

image/jpeg, application/x-ms-application, image/gif, application/xaml+xml, image/pjpeg, application/x-ms-xbap, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*

Por lo tanto vemos como en el campo Accept el cliente nos dice que formatos de respuesta entiende (y en que orden los prefiere).

2. Acceso a la cabecera desde ASP.NET MVC

Imaginad que tenemos un controlador que puede devolver datos en dos formatos: XML y JSON. Y queremos usar el campo Accept de la cabecera http que envíe el cliente para devolver los datos en uno u otro formato.

Acceder a la cabecera http desde un controlador es extremadamente sencillo, usando Request.AcceptTypes, que es un array con todos los campos de la cabecera accept.

3. Devolver datos en formato XML

ASP.NET MVC no trae ningún mecanismo incluído para devolver datos en formato xml, lo que me va de coña para enseñaros como nos podemos crear un ActionResult propio:

public class XmlActionResult : ActionResult
{
    private readonly object _data;
    public XmlActionResult(object data)
    {
        _data = data;
    }
    public override void ExecuteResult(ControllerContext context)
    {
        XmlSerializer ser = new XmlSerializer(_data.GetType());
        context.HttpContext.Response.ContentType = "text/xml";
        ser.Serialize(context.HttpContext.Response.OutputStream, _data);
    }
}

Crear un ActionResult propio es trivial: deriváis de ActionResult y implementáis el método abstracto ExecuteResult y en él hacéis lo que sea necesario (usualmente interaccionar con la Response). En este caso simplemente serializo el objeto que se le pasa con el serializador estándard de .NET. Ah si! Y pongo el content-type a text/xml que es el content-type usado para documentos en XML.

Yo suelo acompañar los ActionResults propios con un método extensor para los controladores, para llamarlos de forma similar a los ActionResults que vienen en el framework. Mi método extensor (trivial) es:

public static class ControllerExtensions
{
    public static XmlActionResult Xml(this ControllerBase @this, object data)
    {
        return new XmlActionResult(data);
    }
}

Y ahora ya puedo realizar la acción de mi controlador:

public ActionResult List()
{
    var data = new GeeksModel().GetAllGeeks();
    return Request.AcceptTypes.Contains("application/json") ?
        (ActionResult)Json(data, JsonRequestBehavior.AllowGet) :
        (ActionResult)this.Xml(data);         
}

Simplemente pregunto si está el accept application/json(*) (que parece ser el content-type para JSON). Si lo está envío los datos en json y si no pues en xml! Si abrimos un navegador y vamos a /Geeks/List veremos los datos en XML porque ningún (bueno, ni FF ni IE que son los que he probado :p) envían application/json en el accept de la request.

(*) Ok, acepto que esta pregunta no es del todo correcta: debería mirar si application/json está preferido antes que text/xml (por si me manda ambos). Igual que teoricamente, debería comprobar si no me manda ninguno de los dos, y si es el caso devolver un error 406.

4. Un detallito final…

Bueno, eso parece funcionar, pero lo que chirría un poco es tener que meter este if() para comprobar en cada acción de cada controlador si la request contiene application/json o no y serializar el resultado en JSON o en XML.

Para evitar esto he encontrado dos alternativas en la red:

Usar otro action result y que sea el action result quien decida si serializar los datos en XML o en JSON. Es decir, crearnos un JsonOrXmlActionResult, devolver siempre una instancia de este action result desde los controladores y en el ExecuteResult, preguntar por el campo accept y serializar en un formato en otro. Esta aproximación la he visto en el post “Create REST API using ASP.NET MVC that speaks both Json and plain Xml” del blog de Omar Al Zabir.

Otra aproximación totalmente distinta (pero muy interesante) que usa un action filter para ello. Está en el blog de Aleem Bawany, en el post “ASP.NET MVC – Create easy REST API with JSON and XML”.

Os recomiendo la lectura de estos dos posts.

Un saludo y gracias a todos, especialmente a Hadi Hariri quien con su comentario anterior, ha motivado este post! :)

PD: Como siempre, esto es un crosspost desde mi blog en geeks.ms! Pásate por allí mejor, que somos más!

Subir ficheros al servidor en ASP.NET MVC

2010-09-08T13:25:00.001+02:00

Buenas! Hoy voy a responder alguna pregunta que me he encontrado en alguna vez, y es como subir ficheros al servidor usando MVC2.

La verdad es que con ASP.NET MVC2 subir ficheros al servidor es extremadamente simple. Vamos a empezar viendo el código de una vista que permite subir un fichero al servidor, junto con una descripción adicional. La vista básicamente contiene un <form> como el siguiente:

<form action="<%: Url.Action("Upload") %>" enctype="multipart/form-data" method="post">
    <label for="descripcion">Descripción del fichero:</label>
    <input type="text" id="descripcion" name="descripcion" />
    <br />
    <label for="fichero">Fichero:</label>
    <input type="file" name="fichero" size="40">
    <br />
    <input type="submit" value="Enviar" />
</form>

Fijaos que es HTML puro y duro, aunque el tag <form> lo podeis generar con Html.BeginForm() si queréis. La clave es añadir el atributo enctype con el valor multipart/form-data. Como se menciona en la especificación sobre formularios del W3C, el valor de multipart/form-data es el que debe usarse cuando se quieran enviar al servidor datos binarios.

El <input type=”file”> es el control HTML que nos permite seleccionar un fichero para enviar.

Y desde el controlador? Pues sencillo, en este caso mi formulario tiene dos parámetros (descripcion y fichero), por lo que necesitaré que la acción del controlador tenga esos dos parámetros. El parámetro descripcion es un string, pero el parámetro fichero… que és?

Pues bien ASP.NET MVC es capaz de ver que el parámetro fichero es un fichero que se ha subido al servidor y sabe mapearlo a un objeto de la clase HttpPostedFileBase. Esta clase nos da acceso no sólo al contenido del fichero subido, sinó a más información (su content-type, su tamaño, el path completo desde donde se ha subido,…).

El método del controlador queda pues, así de sencillo:

[HttpPost]
public ActionResult Upload(string descripcion, HttpPostedFileBase fichero)
{
    fichero.SaveAs(Path.Combine(@"d:\temp", Path.GetFileName(fichero.FileName)));
    return View();
}

Fijaos en los dos parámetros string y HttpPostedFileBase. El método simplemente se guarda una copia del fichero subido en d:\temp, pero obviamente aquí podéis hacer lo que queráis.

Y listos! No hay que hacer nada más… qué, sencillo, no??? :)

Un saludo

PD: Esta técnica no es ajax, eso significa que mientras se está subiendo el fichero al servidor, la aplicación web no responde (el browser está haciendo la petición). Existe un mecanismo para realizar subidas de ficheros en background, aunque no es directo debido a que con XMLHttpRequest (el objeto del naveagador que hace posible ajax) no se pueden subir ficheros. Si estáis interesados en el siguiente post de John Rudolf se muestra como realizar un upload de fichero en ajax usando jQuery y el form plugin!

PD2: Como no, eso es un crosspost desde mi blog en geeks.ms!