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.