viernes, 24 de septiembre de 2010

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

viernes, 10 de septiembre de 2010

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!

miércoles, 8 de septiembre de 2010

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!