CAMBIAR EL ESQUEMA CON ASP.

NET IDENTITY

RodriguezWeb

Cambiar el esquema con ASP.NET Identity

Una de las grandes novedades (probablemente la de mayor calado si obviamos la revolucin de OWIN) de la nueva
versin de ASP.NET es ASP.NET Identity, que sustituye al viejuno Membership (que apareci all en 2005). ASP.NET
Identity est diseado para dar solucin a muchos de los problemas de los que Membsership acaeca.
Una de las preguntas ms recurrentes en los foros de la MSDN y fuera de ellos es como usar Membership con un
esquema de base de datos propio. Esto bsicamente implica crearte un custom memberhip provider lo que, sin ser
excesivamente complicado, te hace bueno derivar de una clase con un porrn de mtodos abstractos, la mitad de los
cuales puede que ni apliquen en tu caso y que vas a dejar llenos de NotImplementedException. Pesado, feo y adems
un NotImplementedException siempre demuestra un fallo de diseo en algn punto del sistema (en este caso en el
Membership).
ASP.NET Identity ha sido diseado, entre otras cosas, para solucionar este problema: que los cambios de esquema de
la BBDD no impliquen tantos problemas. En este post veremos como adaptar ASP.NET Identity a un esquema de
BBDD propio, utilizando, eso s, el proveedor de ASP.NET Identity para Entity Framework. Y es que otras de las
caractersticas de ASP.NET Identity es que puede trabajar con varios proveedores de datos (p. ej. se podra hacer un
proveedor noSQL para MongoDb) aunque, obviamente (no le pidamos peras al olmo) implementar un proveedor nuevo
no es algo trivial. MS ha implementado uno para EF que es el que mucha gente va a utilizar, as que centrmonos en
l. Dicho proveedor reside en el paquete Microsoft.AspNet.Identity.EntityFramework y se incorpora por defecto cuando
seleccionamos la opcin Individual User Accounts al crear un proyecto ASP.NET en VS2013.
Si no hacemos nada, el esquema por defecto que se nos crea es el siguiente:

Miremos ahora alguna de las tablas, p. ej. AspNetUsers:

Bien, veamos ahora como podemos aadir un campo adicional a esta tabla.

Aadiendo un campo adicional a la tabla de usuarios

Honestamente este es la parte fcil (y la que encontrars en la mayora de tutoriales sobre ASP.NET Identity). Pero
antes de ver como hacerlo djame contarte un par de cosillas sobre como est montado el proveedor de ASP.NET
Identity para EF. Dicho proveedor se basa en EF Code First y en varias clases que implementan las interfaces
necesarias para ASP.NET Identity. P. ej. ASP.NET Identity trabaja con la interfaz IUser y el mdulo de EF utiliza la
clase IdentityUser. La interfaz IUser es muy simple, solo define dos campos (Id y UserName ambos de tipo string). La
clase IdentityUser implementa dicha interfaz y aade varios campos ms (como PasswordHash y SecurityStamp).
Podramos decir que la tabla AspNetUsers se genera a partir de dicha clase.
Nosotros no podemos modificar dicha clase y aadir campos, as que el proveedor de ASP.NET Identity para EF ha
optado por ofrecernos otro mecanismo. Dicho proveedor para trabajar necesita un contexto de EF (es decir un
DbContext), pero dicho DbContext debe derivar de IdentityDbContext<T> donde el tipo T derive de IdentityUser. As
pues para aadir un campo simplemente debemos:
1.
2.

Crear una clase X derivada de IdentityUser y aadir el campo necesario.

Derivar de IdentityDbContext<X> donde X es la clase creada en el punto anterior.

El template de VS2013 nos crea una clase llamada ApplicationUser que ya hereda de IdentityUser. Dicha clase est
vaca y est pensada para que nosotros aadamos los campos necesarios. Tambin nos crea un contexto de EF
(llamado ApplicationDbContext) que hereda de IdentityDbContext<ApplicationUser>. Es decir, nos da casi todo el
trabajo hecho :)

Guillermo J Rodrguez Pineda

Pgina 1

CAMBIAR EL ESQUEMA CON ASP.NET IDENTITY

RodriguezWeb

Para no ser originales, vamos a hacer el ejemplo clsico que encontrars en cualquier post: aadir la fecha de
nacimiento. Para ello nos basta con aadir dicho campo en la clase ApplicationUser:
public class ApplicationUser : IdentityUser
{
public string nombres { get; set; }
}
Si ahora ejecutas de nuevo la aplicacin, seguramente te dar el siguiente error: The model backing the
'ApplicationDbContext' context has changed since the database was created. Consider using Code First Migrations to
update the database (http://go.microsoft.com/fwlink/?LinkId=238269)
Esto es porque se ha modificado el esquema de datos y ahora tenemos un cdigo que no se corresponde a la BBDD.
Tenemos dos opciones: o eliminar la BBDD (y perder todos los datos) o usar Migrations. Para usar Migrations tenemos
que habilitarlas primero mediante el Package Manager Console, tecleando Enable-Migrations. Una vez las tengas
habilitadas debemos:
1.
2.

Aadir una migracin que refleje el cambio realizado en ApplicationUser, usando Add-Migration
<nombre_migracion> en el Package Manager Console
Actualizar la BBDD usando Update-Database en el Package Manager Console.

En mi caso cuando he tecleado Add-Migration AddBirthday me ha generado dentro de una carpeta Migrations el
archivo de migracin. Dicho archivo es una clase C# que le indica a Migrations que hacer. Se genera automticamente
comparando el esquema de la BBDD con el esquema que tendra que haber segn la clases de EF code first. Para
que veas, en mi caso la clase de migracin contiene el siguiente cdigo:
public partial class AgregarColumna : DbMigration
{
public override void Up()
{
AddColumn("dbo.AspNetUsers", "nombres", c => c.String());
}
public override void Down()
{
DropColumn("dbo.AspNetUsers", "nombres");
}
}
Puedes ver que lo que har es aadir la columna BirthDay. Insisto: dicha clase se genera automticamente al hacer
Add-Migration. Cuando ejecutes Update-Database, se aplicarn los cambios indicados.
As que bueno lo nico que te queda es esto, ejecutar el comando Update-Database desde el Package Manager
Console. Cuando lo apliques vers algo parecido a esto:

Listos Si ahora miras el esquema de la tabla AspNetUsers vers que tenemos ya el nuevo campo:

Fcil y sencillo. La verdad, comparado con lo que se tena que hacer para conseguir lo mismo con el Membership es
una maravilla :P
Cambiar el esquema
Vale aadir campos es sencillo (hemos visto el ejemplo clsico que es la tabla de usuarios, para el resto de tablas es
lo mismo pero con otras clases). Pero y cambiar el esquema? Si quiero que la tabla AspNetUsers se llame
simplemente Users y que PasswordHash se llame Pwd p. ej.? Que tenemos que hacer?

Guillermo J Rodrguez Pineda

Pgina 2

CAMBIAR EL ESQUEMA CON ASP.NET IDENTITY

RodriguezWeb

Pues bien, eso tambin es posible gracias al uso de EF Code First. En este caso vamos a tener que tocar el contexto
de EF (la clase ApplicationDbContext en el caso de cdigo generado por VS2013), en concreto redefinir el mtodo
OnModelCreating:
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
base.OnModelCreating(modelBuilder);
modelBuilder.Entity<IdentityUser>().ToTable("Users").
Property(u => u.PasswordHash).HasColumnName("Pwd");
modelBuilder.Entity<ApplicationUser>().ToTable("Users").
Property(u => u.PasswordHash).HasColumnName("Pwd");
}
Y ahora el esquema que tengo en la BBDD es (mantengo mi clase ApplicationUser con la propiedad BirthDay):

De nuevo comparado con lo que se tena que hacer con el antiguo Membership es una maravilla.
El tipo de cambios que puedes hacer vienen limitados por EF Code First, pero en general estamos ante un modelo
mucho ms flexible que el anterior Membership.
En resumen, a pesar de que ASP.NET Identity tiene varias cosillas que no me gustan (o mejor dicho, realmente varias
cosas que echo en falta) es sin duda un paso adelante respecto al anterior Membership. Me sigue quedando la duda de
si lo que ofrece es suficiente para segn que tipo de webs, pero si las funcionalidades que ofrece te son suficientes y
no te importa ajustar tu esquema a algunos detalles menores (como esos Id de usuario de tipo string) es un avance
muy significativo respecto a Membership.

Guillermo J Rodrguez Pineda

Pgina 3