How do I associate my application data to a user in a ASP.NET MemberShipProvider?

I'm just starting out learning ASP.NET MVC. I'm working on a project created with the standard project template which by default uses a SqlMembershipProvider. This has automatically created a ASPNETDB.mdf database in my project to hold membership information. How can I associate the members stored in this database with my actual application data?

Should I simply reference the current user's name in my action methods using this.User.Identity.Name to use as a key when storing or retrieving user specific information to and from my application's database? Or should I be using this.User.Identity.UserId instead? I always thought integer based IDs were much faster to look up vs string or GUID base IDs. But the primary key of the aspnet_Users table is a GUID field.

Is there any difference between this.user vs this.HttpContext.User? What about the IPrincipal returned from these properties vs the MembershipUser开发者_开发百科 returned from Membership.GetUser(). What is the difference between these?

Also, is it best to keep the membership information in a separate database from the application database? Or is it ok to merge them together into a single database?

There's a few elements to your question, a few points:

I normally use the identity name as it's typically more efficient to use. The get user function gets the full user data from the database and updates the last access time. The IPrinciple doesn't require this and uses in memory data. As such the username property is quicker and more readily available. The main caveat would be if you might allow users to change their user name, in which case the ID would make more sense.

It sounds like you are making considerations for having a lot of user related records. You are right, integers are the quickest to look up. If you have large volumes of data then you might want to map your users to an integer, either by extending the membership provider or by adding a mapping table.

As for the this.User vs HttpContext.User, no difference.

The default template should give you an "AccountModel" in the Models folder which creates wrappers for some of the formsauthentication/membership functions. you can extend on that and add a function to return the current "HttpContext.Current.User" which is an IPrincipal stored in the current HttpContext. With the Name property from that you could query Membership by username to get the Membership data (the IPrincipal just stores the very basics such as username,roles,etc the MembershipUser has all the other data pulled from the db).

The SqlMembershipProvider is pretty crappy imo and limiting other than for small projects...and at the same time waay to complicated. I'm using it now on a site with 2000+ accounts and it's a pita if you want to customize anything. It's better off (and there is lots of examples on the net) just to write your own that uses formsauthentication and get rid of the Membership crap. I have one now I wish I wrote one to begin with.

In apps where I have used SqlMembershipProvider, I have typically stored its tables/sprocs in the same DB as my application tables and then linked my app tables to the user tables using a foreign key. The one time I didn't do it this way was when one user database was going to be shared between multiple distinct applications that each had their own app database.