Culbertson Exchange

Continuing on the previous post about using the drop-in Altairis.Web.Security membership provider, I ran into an issue where the database may not be recreated in a timely fashion on a change to the model classes. For example if you add the following property to the User class:

public string FullName { get; set; }

And change the initializer in the ApplicationDB.cs class to drop and create the database on model change:

public class DBInitializer : DropCreateDatabaseIfModelChanges<ApplicationDB>

The problem is if you then access the database by creating a new user in the “Account/Register” controller, the database will not drop and create because the Altairis membership provider uses non-EF (ADO.Net classic) methods of data access. Therefore, the Entity Framework access methods haven’t been touched yet and won’t drop/create the DB until that time.

The solution is to add a section to the Application_Start() method in the Global.asax:

protected void Application_Start() {
     AreaRegistration.RegisterAllAreas();

     // Initializes and seeds the database.
     Database.SetInitializer(new DBInitializer());

     // Forces initialization of database on model changes.
     using (var context = new ApplicationDB()) {
          context.Database.Initialize(force: true);
     }

     RegisterGlobalFilters(GlobalFilters.Filters);
     RegisterRoutes(RouteTable.Routes);
}

The code in lines 8-10 forces the context to initialize the database and if there is a model change then it will drop and recreate the database on start of the application, before it can be accessed by the non-EF methods.

The example ASP.Net MVC3 application has been updated with these changes and is available for download at Github: Download Code

Problem with Current Membership/Role Provider

I’ve always thought the default membership/role provider for ASP.Net is a bit heavy in that it is targeted by default to a different database than the main application database and takes several additional steps to set up and deploy. I found the Altairis Web Security Toolkit on CodePlex and it has a nice, simple schema that is easy to integrate that into your application database. It is also available from Nuget as Altairis.Web.Security.

Working with the EF Magic Unicorn Edition

The new Entity Framework Code First, also known as the “EF Magic Unicorn Edition” provides a nice way to generate the database and the ORM from POCO (Plain Old CLR Objects) classes that you write up front. This gives a nice “code first” approach where the domain objects drive the database rather than vice-versa (also known as “persistence ignorance”).

With the current edition of Magic Unicorn the database is constantly being regenerated during development, which interrupts the workflow to do the additional step of adding the membership/role tables. And even if that’s not too much trouble the membership/role tables aren’t accessible to the code first EF context for access by the application.

Code First Integration with the Drop-in Altairis Provider

One solution, besides writing a provider from scratch, is to create code first classes that generate the database schema that is expected by the drop-in membership provider.  That way the membership provider still works as expected without change, and the user/role classes are available to the application for doing administration and easily adding additional columns for the User table.

To implement this I did the following steps for an MVC3 project:

1. Start a new MVC3 web application project.
2. Use the NuGet console to download the following packages:
   Altairis.Web.Security
   EntityFramework
3. Create User and Role classes and include them in a class that defines the EF context. In the context class I did a few special things to make sure that the many-to-many table for the roles was generated correctly:

public class ApplicationDB : DbContext
{
    public DbSet<User> Users { get; set; }
    public DbSet<Role> Roles { get; set; }

    protected override void OnModelCreating(DbModelBuilder modelBuilder) {
        // Maps to the expected many-to-many join table name for roles to users.
        modelBuilder.Entity<User>()
        .HasMany(u => u.Roles)
        .WithMany(r => r.Users)
        .Map(m =>
        {
            m.ToTable("RoleMemberships");
            m.MapLeftKey("UserName");
            m.MapRightKey("RoleName");
        });
    }
}

Data may also be seeded into the initial database, for example to create some default roles. The commented out class definition can be utilized during development to recreate the database if the model changes:

// Change the base class as follows if you want to drop and create the database during development:
// public class DBInitializer : DropCreateDatabaseIfModelChanges<ApplicationDB>
public class DBInitializer : CreateDatabaseIfNotExists<ApplicationDB>
{
    protected override void Seed(ApplicationDB context)
    {
        var roles = new List<Role>{
            new Role{RoleName = "Administrator"},
            new Role{RoleName = "User"},
            new Role{RoleName = "PowerUser"}
        };

        roles.ForEach(r => context.Roles.Add(r));
    }
}

The classes themselves are straightforward and can be decorated with attributes that integrate well with MVC:

public class User {
    [Key]
    [Required(ErrorMessage = "User Name is required")]
    [Display(Name="User Name")]
    [MaxLength(100)]
    public string UserName { get; set; }

    [Required]
    [MaxLength(64)]
    public byte[] PasswordHash { get; set; }

    [Required]
    [MaxLength(128)]
    public byte[] PasswordSalt { get; set; }

    [Required(ErrorMessage = "Email is required")]
    [MaxLength(200)]
    public string Email { get; set; }

    [MaxLength(200)]
    public string Comment { get; set; }

    [Display(Name = "Approved?")]
    public bool IsApproved { get; set; }

    [Display(Name = "Crate Date")]
    public DateTime DateCreated { get; set; }

    [Display(Name = "Last Login Date")]
    public DateTime? DateLastLogin { get; set; }

    [Display(Name = "Last Activity Date")]
    public DateTime? DateLastActivity { get; set; }

    [Display(Name = "Last Password Change Date")]
    public DateTime DateLastPasswordChange { get; set; }

    public virtual ICollection<Role> Roles { get; set; }

}

public class Role {
    [Key]
    [Display(Name = "Role Name")]
    [Required(ErrorMessage = "Role Name is required")]
    [MaxLength(100)]
    public string RoleName { get; set; }

    public virtual ICollection<User> Users { get; set; }
}

Additional properties could be added to the User class and they wouldn’t interfere with the operation of the membership provider as long a they are not “Required” properties.

I wrote an example ASP.Net MVC3 application and it is available for download at Github: Download Code

Update: I found an issue with database initialization if the model is changed and the EF data access is not initialized before the classic ADO.Net access provided by Altairis. See this post for more information.