ASP.NET MVC3 Beta: Mis impresiones

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:

1. 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);
   }

   
   
   
   
   
   



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



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

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…

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:

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



2. Los posts de Scott Guthrie sobre EF Code First:
   
   
   
   1. http://weblogs.asp.net/scottgu/archive/2010/07/16/code-first-development-with-entity-framework-4.aspx
   
   
   
   2. http://weblogs.asp.net/scottgu/archive/2010/07/23/entity-framework-4-code-first-custom-database-schema-mapping.aspx
   
   
   
   3. http://weblogs.asp.net/scottgu/archive/2010/08/03/using-ef-code-first-with-an-existing-database.aspx
   
   
   
   

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

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:

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



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

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!

Opinión: bool es sólo para true/false

Saludos a todos! Tanto a los que estéis trabajando, cómo aquellos que estando de vacaciones seais tan frikis que leais geeks.ms! :)

Hoy quiero hablar un poco sobre bool. Puede parecer un tipo de datos aburridote: a fin de cuentas sólo puede tener dos valores, pero precisamente ahí radica su gracia y de eso os quería contar. La idea del post es muy simple: bool es sólo para true/false.

Por ejemplo, en los arcanos tiempos en que un servidor usaba Visual C++ 6 para el desarrollo de aplicaciones windows, en las MFCs había un método muy divertido llamado UpdateData (que por lo que veo aún está). MFC tenía una cosa muy buena que era la posibilidad de realizar bindings entre variables de la clase que representaba la ventana (usualmente una clase derivada de CWnd) y los controles que contenía dicha ventana. Eso, ahora, puede parecer una chorrada pero por aquel entonces era una auténtica pasada.

El método UpdateData era el que se encargaba de realizar dicho binding. Se llamaba con un parámetro BOOL que si valía TRUE significaba que se pasaban los datos de los controles a las variables y si valía FALSE pues era al revés: se pasaban los datos de las variables a los controles. Eso lo acabo de leer ahora en la MSDN, pero cuanda usaba MFC lo tenía que leer a menudo: nunca me acordaba cual era el significado de TRUE y FALSE en este contexto… En el fondo el parámetro de dicha función no es true/false es “BindingDeControlesAVariables” o “BindingDeVariablesAControles”, es decir un enum con dos opciones.

Y a eso me refiero en este post: un enum con dos opciones no es un booleano, aunque en ambos casos tengamos sólo dos valores posibles. Establecer arbitrariamente un valor a true y otro a false sólo hace que la gente se confunda.

Que código creéis que es más legible?

Fichero.Abrir("foo.txt",true);

O bien:

Fichero.Abrir("foo.txt",ModoApertura.Lectura);

En el primer caso, el segundo parámetro es un bool que si vale true se abre el fichero para lectura y si es false, pues se abre para escritura. Pues vale, pero es una decisión arbitraria y cuando alguien deba usar Abrir probablemente deba consultar que hace exactamente este parámetro bool (y lo mismo si alguien revisa código).

Pero no sólo es por legibilidad de código… Podéis asegurar que dos opciones serán siempre dos opciones? Me explico, y esta vez, como nadie (ni mucho menos yo) está libre de pecado, con un ejemplo de cosecha propia.

En un framework que estamos desarrollando para permitir desarrollos de aplicaciones con ciertas características hay una propiedad de una clase (llamésmola Aplicacion) que indica si cuando se va a la pantalla anterior (las aplicaciones tienen navegación parecida a la de un browser) se debe destruir la vista de la cual se proviene o bien dicha vista se mantiene en memoria.

En su momento implementamos dicha propiedad con un bool (true = destruir la vista, false = no destruirla). Y estuvo bien… hasta cierto día.

Cierto día, nos vimos en la necesidad de que en ciertas aplicaciones la vista se debía destruir sólo si no contenía datos (en caso contrario se podía reaprovechar). A priori esto dependía de cada aplicación. Y ahí tuvimos el problema: como mapeamos esto en nuestra propiedad booleana? Porque ahora teníamos tres valores:

1. No destruir la vista



2. Destruir la vista siempre



3. Destruir la vista sólo si no tiene datos

Nosotros solucionamos el problema añadiendo una segunda propiedad que fuese “que tipo de destrucción de vistas se quería”, y lo hicimos así, simplemente porque todas estas propiedades estaban serializadas en XML (en archivos que algunos ya estaban en producción), por lo que la propiedad original debía ser siendo bool. Total, ahora tenemos dos propiedades a establecer para un mismo comportamiento lo que es susceptible de errores y de confusión. Y todo por no haber usado en su momento un enum :)

Así pues, un consejo: cuando creeis propiedades bool, aseguraos de que realmente un bool es lo que necesitais y no un enum (aunque sea con dos opciones!).

Un saludo!!!!

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

Opinión: De los atributos y su uso…

Sí, ya sé: estamos en Agosto y lo que más seduce ahora mismo es darse un bañito en la playa y salir de copas a rebentar los mojitos del bar, así que los que podáis hacedlo sin dudar… Total, este post tampoco se largará a ninguna parte luego… :)

Los que no estéis de vacaciones o bien prefiráis leer geeks.ms en pleno Agosto (hay de todo en la viña del señor) a ver que os parece este post… es mi opinión sobre el uso que se da a los atributos y los “problemas” que a mi parecer conlleva dicho uso. Dado que es un post de opinión vuestros comentarios sobre vuestras opiniones serán muy bien recibidos (de hecho siempre lo son, simplemente en este post lo serán más si cabe).

He estado observando en determinados casos un uso de los atributos que no me termina de convencer… Para aclarar conceptos entiendo por atributos aquellas clases que derivan de System.Attribute y que usamos para decorar nuestras clases, métodos, propiedades…

Voy a centrar este artículo de opinión en Data Annotations, pero no es el único caso que tiene este “defecto”…

En mi opinión los atributos deberían representar sólamente metadatos, es decir mera información, sin comportamiento alguno definido… O dicho de otro modo no deberían tener ningún método, sólo propiedades.

Cojamos el siguiente código de ejemplo, que es lo más simple del mundo: una clase, con una sola propiedad decorada con [Required]. Dicho atributo indica que la propiedad que se decora con él debe tener un valor:

class Foo
{
    [Required]
    public string Bar { get; set; }
}

Bien, ahora dado el siguiente código:

Foo foo = new Foo();
foo.Bar = string.Empty;
bool b = ((RequiredAttribute)foo.GetType().
    GetProperty("Bar").GetCustomAttributes(false)[0]).
    IsValid(foo.Bar);

Cuál es el valor de b, en este punto?

La respuesta rápida es… depende de la implementación del método IsValid que está en RequiredAttribute. En este caso el valor de IsValid es false, porque string.Empty asume que no es un valor válido.

Y aquí es donde, a mi, me chirría todo un poco… Yo estoy marcando un valor como requerido (usando [Required]) pero no entiendo porque la implementación de Required decide que significa ser requerido dentro de mi aplicación. Es decir el mero de hecho de declararlo como requerido me obliga a una implementación concreta de que signfica “ser requerido”.

En mi lógica de negocio requerido puede significar que no valga null (siendo string.Empty un valor válido, cosa que no acepta el RequiredAttribute). Me diréis que me puedo crear mis propios atributos y tendréis toda la razón del mundo pero entonces si aplico a la propiedad Bar de la clase Foo un atributo mío, estoy cambiando los metadatos de dicha clase… que pasa si la clase es externa o bien quiero usarla en distintos proyectos (donde el concepto de requerido puede ser diferente)?

No se si sería mejor separar RequiredAttribute en dos clases: una que sea el atributo que marque el elemento como requerido y otro que sea “que significa que un elemento sea requerido (es decir el método IsValid)” (dejadme llamar AttributeHandler a estas clases por ponerles nombre). Obviamente el framework debería proporcionar un AttributeHandler asociado a cada atributo y debería darme un mecanismo para que yo pudiese indicar que en mi proyecto el AttributeHandler para la clase RequiredAttribute es la clase que yo quiera…

No sé si me entiende por donde voy… :)

Un (caluroso) saludo a todos!

PD: Un efecto colateral de tener atributos con cierto comportamiento es que estos empiezan a tener dependencias a terceros componentes (imaginaros un atributo tipo [Log]… que usa para generar los ficheros de log?). Y dado que los atributos los crea el CLR eso hace difícil inyectarles dependencias… Si el código que tiene el comportamiento (p.ej. el que hace log) estuviese en otras clases que no se creasen automáticamente por el CLR sería más fácil inyectarles dependencias).

PD2: Esto es un crosspost desde mi blog en geeks.ms (como todos)!