Customizing SimpleMembership Provider

Question

I am using simple membership provider in mvc4 application and I can see five tables generated for that. In that i can see username and password are stored on different tables. I want to save username and password on the same table with some custom fields. So I am creating my own Membership Provider by inheriting ExtendingMembership Provider. I have some queries over that.

1. My application uses 3-tier architecture(BLL, DAL and Presentation layers) and created 2 areas for account and admin. So here i dont know where to place my membership provider which are then accessed with every part of application for using Authorize Attribute.

2. I am overriding this method CreateUserAndAccount, Do i need to implement my own logic for saving user registration datas to database. But i find only some parameters are passed, how to pass my remaining custom fields from view to the controller using the dictionary object ?

   public override string CreateUserAndAccount(string userName, string password, bool     requireConfirmation, IDictionary<string, object> values)
   {
       throw new NotImplementedException();
   }
   

Answer 1

For #1: Use DI to inject ExtendedMembershipProvider into your BLL layer as required. Map it in your DI configuration to Membership.Provider. This is effectively a DAL and should not contain business logic. Better still create a facade around WebSecurity and inject that into your BLL instead.

For #2: Yes the ExtendedMembershipProvider interface uses a dictionary of Key/Value pairs which can be used to map user profile properties to the database schema using an implementation of your choosing.

SimpleMembershipProvider does this by mapping the dictionary keys to corresponding database columns. Once the record has been created, you can then manage the user data using EF and the UserProfile model directly.

Implementing your own ExtendedMembershipProvider is a lot of work and I wouldn't recommend it. The SimpleMembershipProvider schema is relatively clean compared to legacy iterations, and I think you would need a very good reason for wanting to move password column to the user table, rather than just configuring SimpleMembershipProvider to use your own schema, and leaving password where it rightly belongs.

Answer 2

As for question #2: Check out this question I asked this weekend... SimpleMemership CreateUserAndAccount Customization - specifically the blog post I linked in the question as it's very helpful about extending SimpleMembership.