.NET Boilerplate Libraries – Optimizing ASP.NET Projects

You can create a User class that has nothing to do with ASP.NET Identity in your core library.

public class User {
    public Guid UserId { get; set; }
    public string UserName { get; set; }
    public string EmailAddress { get; set; }
    public string EmailAddressConfirmed { get; set; }
    public string PhoneNumber { get; set; }
    public string PhoneNumberConfirmed { get; set; }
    public string PasswordHash { get; set; }
    public string SecurityStamp { get; set; }

    ...

    public virtual ICollection<Role> Roles { get; set; }
    public virtual ICollection<UserClaim> UserClaims { get; set; }
    public virtual ICollection<UserLogin> UserLogins { get; set; }
}

If you're using Entity Framework, create a configuration class for your entities (optional).

internal class UserConfiguration : EntityTypeConfiguration<User>
{
    internal UserConfiguration()
    {
        ToTable("User");

        HasKey(x => x.UserId)
            .Property(x => x.UserId)
            .HasColumnName("UserId")
            .HasColumnType("uniqueidentifier")
            .IsRequired();

        Property(x => x.PasswordHash)
            .HasColumnName("PasswordHash")
            .HasColumnType("nvarchar")
            .IsMaxLength()
            .IsOptional();

        Property(x => x.SecurityStamp)
            .HasColumnName("SecurityStamp")
            .HasColumnType("nvarchar")
            .IsMaxLength()
            .IsOptional();

        Property(x => x.UserName)
            .HasColumnName("UserName")
            .HasColumnType("nvarchar")
            .HasMaxLength(256)
            .IsRequired();

        // EmailAddress, PhoneNumber, ...

        HasMany(x => x.Roles)
            .WithMany(x => x.Users)
            .Map(x =>
            {
                x.ToTable("UserRole");
                x.MapLeftKey("UserId");
                x.MapRightKey("RoleId");
            });

        HasMany(x => x.UserClaims)
            .WithRequired(x => x.User)
            .HasForeignKey(x => x.UserId);

        HasMany(x => x.UserLogins)
            .WithRequired(x => x.User)
            .HasForeignKey(x => x.UserId);
    }
}

You'd have to also create classes for Role, UserClaim, and UserLogin. You can name them whatever you choose if you don't like the above names.

In the web layer, create a class called AppUser (Or another name if you choose). This class should implement the ASP.NET Identity IUser<TKey> interface, where TKey is the data type for the primary key (Guid in the above example).

public class AppUser : IUser<Guid>
{
    public AppUser()
    {
        this.Id = Guid.NewGuid();
    }

    public AppUser(string userName)
        : this()
    {
        this.UserName = userName;
    }

    public Guid Id { get; set; }
    public string UserName { get; set; }
    public string EmailAddress { get; set; }
    public string EmailAddressConfirmed { get; set; }
    public string PhoneNumber { get; set; }
    public string PhoneNumberConfirmed { get; set; }
    public string PasswordHash { get; set; }
    public string SecurityStamp { get; set; }
}

Change all references to UserManager in the web project to UserManager<AppUser, Guid>.

Finally, create your own UserStore. Essentially, the custom UserStore will take in the AppUser object, convert it to an User entity object, then persist it. An example of one of these methods is shown below:

public class UserStore : 
    IUserLoginStore<AppUser, Guid>, 
    IUserClaimStore<AppUser, Guid>, 
    IUserRoleStore<AppUser, Guid>, 
    IUserPasswordStore<AppUser, Guid>, 
    IUserSecurityStampStore<AppUser, Guid>, 
    IUserStore<AppUser, Guid>, 
    IDisposable
{
    private User MapFromAppUser(AppUser appUser)
    {
        if (appUser == null)
            return null;

        var userEntity = new User();

        PopulateUser(userEntity, appUser);

        return userEntity;
    }

    private void PopulateUser(User user, AppUser appUser)
    {
        user.UserId = appUser.Id;
        user.UserName = appUser.UserName;
        user.EmailAddress = appUser.EmailAddress;
        user.EmailAddressConfirmed = appUser.EmailAddressConfirmed;
        user.PhoneNumber = appUser.PhoneNumber;
        user.PhoneNumberConfirmed = appUser.PhoneNumberConfirmed;
        user.PasswordHash = appUser.PasswordHash;
        user.SecurityStamp = appUser.SecurityStamp;

        // First name, last name, ... 
    }

    #region IUserStore<AppUser, Guid> Members

    public Task CreateAsync(AppUser appUser)
    {
        if (appUser == null)
            throw new ArgumentNullException("appUser");

        var userEntity = MapFromAppUser(appUser);

        // Persist the user entity to database using a data repository.
        // I'll leave this to you.
    }

    ...

    #endregion
}

To get a full description of a possible implementation, click here.

In the end, it's your choice. Measure the amount of effort it would take for you to maintain this implementation versus just referencing the Identity framework in your Core library. Personally, I thought of doing it the way I described above, however, I didn't because I'd potentially have to change my code every time the ASP.NET Identity framework is updated.

Hopefully this helps and answers your question!

For a site this large, I'm going to recommend a gradual transition.

1. Determine if you have a web site or a web application.

   Asp.Net Web applications bring a lot of their own benefits, but the most important one for you is that they have a "mixed mode" and can run both Webforms and MVC from the same application. If you have a site, you'll need to migrate to an app. It's a simple and relatively safe process. Shouldn't take more than a day or two.

2. Identify the parts of your code that are painful to work with or change often.

   These are your first targets. You'll get the biggest bang for your buck if you tackle these first. There's no sense in "fixing" code that never changes.

3. Invest in a refactoring tool like ReSharper.

   I seriously could not imagine undertaking such a project without a tool that helps you quickly and, more importantly, safely clean up your code.

4. Introduce a new class library project to house your data access and common business logic.

   The project is going to be in a state of flux for some time (perhaps forever). You're going to want to centralize logic & functionality that's common to your Forms and Controllers.

   At this point, you may or may not want to introduce Entity Framework. The safest thing to do is to extract your data access into this library, introduce an interface to it and replace the ADO.Net data later with a shiny new EF one later.

5. Have a plan.

   A project that this will quickly become a quagmire if you don't have realistic, obtainable milestones.

Lastly, consider whether you really need to move to MVC to clean this up, or if it would be sufficient to learn the Model-View-Presenter pattern and refactor your existing code into it. It's a flavor of MVC (the pattern, not the framework) that works very well with Webforms. Properly applied, it will give you many of the architectural benefits that MVC will give you.