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!!! 🙂

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! 🙂

ASP.NET MVC: Mostrar datos en HTML o PDF (pero en el fondo vamos a hablar de la tabla de rutas).

El otro día, uno de los grandes de Webforms (al que, aún que a veces despotrique un poco, MVC le está empezando a gustar :P), publico un excelente artículo sobre como generar PDFs usando MVC. En el artículo Marc mostraba como mostrar datos de un PDF físico en disco o bien usando una vista parcial para generar PDFs al vuelo.

Su artículo me sirve de excusa perfecta para escribir un artículo sobre como podríamos aplicar su solución a un caso más general: vamos a ver como podemos mostrar una misma vista ya sea en formato HTML o bien en PDF. De nuevo, antes que nada leeros el artículo de Marc, ya que este está basado en aquel.

El objetivo que pretendemos es que dada una url, p.ej. http://host/geeks/list nos muestre la información en formato HTML o bien en formato PDF. La primera cosa a resolver es como indicar si queremos que el formato de salida sea pdf o html… Las dos maneras que quizá se os ocurran primero son:

  1. Añadiendo un parámetro de ruta, de forma que tendremos una URL tipo /geeks/list/pdf o /geeks/list/html. No me convence porque no queda claro que este parámetro no es de “negocio”. Me explico, una URL que para ver mis datos podría ser /geeks/view/pdf/edu. El parámetro ‘edu’ és claramente de negocio, pero el parámetro pdf, no…
  2. Añadiendo un parámetro en querystring, de forma que tendremos una URL tipo /geeks/list?format=pdf. No me convence porque aunque MVC se defiende bien con parámetros en querystring, realmente son totalmente innecesarios (y rompen la “amigabilidad” de las URLs que promulga MVC).

Un dia navegando por la MSDN vi otra opción que me pareció interesante. P.ej. si vais a http://msdn.microsoft.com/library/system.string(v=VS.90).aspx obteneis la información de string para el framework 3.5, mientras que si vais a http://msdn.microsoft.com/library/system.string(v=VS.80).aspx la que obteneis es la información para el framework 2.0. El parámetro (v=xxx) indica la versión para el que mostrar información.

Podemos conseguir fácilmente algo parecido en MVC? Pues… por supuesto! 😉

1. La tabla de rutas

La tabla de rutas es uno de los aspectos más desconocidos de ASP.NET MVC. Mucha gente asume que la convención de URLs /controlador/accion/id es una obligación, pero ni mucho menos: las URLs en ASP.NET MVC pueden tener cualquier forma y se definen usando la tabla de rutas. La forma /controlador/accion/id es sólamente la configuración estándard de la tabla de rutas (y digo estándard y no por defecto porque la tabla de rutas inicialmente está vacía, pero el wizard de VS nos genera el código para rellenarla usando dicha convención).

El código para configurar la tabla de rutas está en Global.asax.cs y el código que genera VS es tal y como sigue:

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

La primera sentencia es para que MVC ignore las rutas de tipo algo.axd/algomás (estas URLs pertenecen al sistema de trace de ASP.NET) y la segunda sentencia es la interesante. En ella se mapean las URLs con el formato /controlador/accion/id, y no sólo eso, sinó que se asignan valores por defecto (contrrolador vale Home, accion vale index y id es opcional y no tiene valor). Es por eso que la URL / en MVC equivale a /Home que equivale a /Home/Index.

Lo que ponemos entre llaves ({}) en la definición de la URLs son las variables de la tabla de rutas. El resultado de procesar una URL mediante la tabla de rutas es un conjunto de valores, que conocemos con el nombre de Route Values. Hay dos Route Values que el sistema MVC debe ser capaz de extraer de cada URL: controller y action. El resto de route values son pasadas como parámetros al controlador. Cuando usamos MapRoute para añadir una ruta a la tabla de rutas, le pasamos la mayoría de veces tres parámetros:

  1. Un nombre de ruta
  2. El formato de las URLs que acepta dicha ruta. Lo que esté entre llaves es variable y se mapeará a una route value
  3. El valor de las route values por defecto cuando no se puedan mapear a partir de la URL.

Las URLs que queremos obtener son URLs del siguiente tipo: /geeks/list(pdf) o /geeks/list(html). Obviamente quiero poder añadir parámetros después, es decir /geeks/list(pdf)/edu debe funcionar. Y también quiero que las URL clásicas (/geeks/list o bien /geeks/list/edu) funcionen bien (generando la salida en HTML).

La tabla de rutas que hace posible esas URLs es tal y como sigue:

routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
routes.MapRoute(
"WithDevice", // Route name
"{controller}/{action}({device})/{id}", // URL with parameters
new { controller = "Home", action = "Index", device = "html", id = UrlParameter.Optional }
);

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

Fijaos en los dos MapRoute:

  1. El primero mapea URLs del tipo controlador/accion(formato)/param. Los paréntesis deben aparecer. Es decir una url del tipo /geeks/list(pdf)/edu será procesada por esa ruta y asignará los route values:
    1. controller = geeks
    2. action=list
    3. device=pdf
    4. id=edu
  2. Si una URL no tiene este formato (no tiene los paréntesis) no se procesará por la primera ruta y entrará por la segunda. Esta segunda ruta es la clásica de ASP.NET MVC. La única diferencia es que asigna el valor del route value a html. Así pues una url del tipo /geeks/list/edu será procesada por esta segunda ruta (y obtendremos los mismos route values que el caso anterior).

Ahora que ya podemos procesar las URLs que nos interesan, ya podemos generar la salida en formato PDF o HTML, según el valor del route value device.

2.El controlador

El controlador es muy simple. En el ejemplo sólo tengo una acción (List) que devuelve un listado de geeks. No me interesa el parámetro id, pero si el parámetro device (para saber si debo generar la salida en  pdf o html) así pues, declaro el controlador:

public ActionResult List(string device)
{
IEnumerable<GeeksViewModel> geeks = new GeeksModel().GetAllGeeks();
return "pdf".Equals(device, StringComparison.InvariantCultureIgnoreCase) ?
this.Pdf(geeks) : View(geeks);
}

Fijaos como la acción recibe el parámetro device, cuyo valor será el valor del route value device… Os he dicho que me encanta MVC? 🙂

Lo que hace el controlador es poca cosa: obtiene una lista de objetos GeeksViewModel y luego o bien llama a View() para pasar dichos datos a la vista, o bien llama a Pdf que es un método extensor que he hecho, que devuelve los datos en pdf.

El código del método extensor (totalmente basado en lo que publicó Marc) es el siguiente:

public static class ControllerExtensions
{
public static ActionResult Pdf(this ControllerBase @this)
{
return Pdf(@this, null);
}

public static ActionResult Pdf(this ControllerBase @this, object model)
{
byte[] buf = null;
MemoryStream pdfTemp = new MemoryStream();
ViewEngineResult ver = ViewEngines.Engines.FindView(@this.ControllerContext,
@this.ControllerContext.RouteData.Values["action"].ToString(), null);
if (ver.View != null)
{
if (model != null)
{
@this.ViewData.Model = model;
}
string htmlTextView = GetViewToString(@this.ControllerContext, ver);
iTextSharp.text.Document doc = new iTextSharp.text.Document();
iTextSharp.text.pdf.PdfWriter writer = iTextSharp.text.pdf.PdfWriter.GetInstance(doc, pdfTemp);
writer.CloseStream = false;
doc.Open();
AddHTMLText(doc, htmlTextView);
doc.Close();
buf = new byte[pdfTemp.Position];
pdfTemp.Position = 0;
pdfTemp.Read(buf, 0, buf.Length);
}
return new System.Web.Mvc.FileContentResult(buf, "application/pdf");
}

private static void AddHTMLText(iTextSharp.text.Document doc, string html)
{

List<iTextSharp.text.IElement> htmlarraylist = HTMLWorker.ParseToList(new StringReader(html), null);
foreach (var item in htmlarraylist)
{
doc.Add(item);
}

}

private static string GetViewToString(ControllerContext context, ViewEngineResult result)
{
string viewResult = "";
TempDataDictionary tempData = new TempDataDictionary();
StringBuilder sb = new StringBuilder();
using (StringWriter sw = new StringWriter(sb))
{
using (HtmlTextWriter output = new HtmlTextWriter(sw))
{
ViewContext viewContext = new ViewContext(context, result.View, context.Controller.ViewData, context.Controller.TempData, output);
result.View.Render(viewContext, output);
}
viewResult = sb.ToString();
}
return viewResult;
}
}

Las únicas diferencias respecto el código que puso Marc son:

  1. El uso de vistas completas (en lugar de una vista parcial)
  2. El soporte para pasar a la vista un modelo
  3. El uso del ViewData y del TempData que tenga el controlador (en lugar de crear un ViewData y un TempData vacío)
  4. Que la vista se selecciona a través del nombre de acción en lugar de ser una vista concreta.

El resto es tal y como estaba el código de Marc (porque ya os digo que yo iTextSharp no es que lo domine mucho :P).

Y el resultado? Pues si llamamos a /Geeks/List o /Geeks/List(html) tenemos:

image

Mientras que si llamamos a /Geeks/List(pdf) el resultado es:

image

3. Conclusiones

Lo interesante del post no es ver como generar PDFs (de eso ya se encarga el post de Marc), lo interesante es ver como gracias a la tabla de rutas podemos crearnos nuestras propias URLs de forma muy sencilla!

Un saludo a todos y gracias a Marc por el post que me ha dado la excusa para escribir este! 😉

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!