2

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?

Eric Anastas
  • 21,675
  • 38
  • 142
  • 236

3 Answers3

1

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.

maciek
  • 661
  • 4
  • 10
  • 1
    With all due respect, I disagree. I've used the membership provider for very high load sites. If you're having trouble with that few users I'd say you've got some issues with your servers. The whole point of the membership provider is to help you not have to do repetitive tasks like this yourself and get the first chunk of development done. If you want to extend it it's dead easy too... – Timbo Apr 18 '11 at 20:37
  • Well the AccountMembershipService and FormsAuthenticationService classes created by default in AccountModel.cs really only wrap the functionality in the MembershipProvider and FormsAuthentication classes respectively. So I'm trying to understand what's really going on behind the scenes. This is my first ASP.NET project ever so I'm not too concerned with any limitations of the SqlMembershipProvider. Will the Http.Context.User always refer to the same user as MemberShip.GetUser()? – Eric Anastas Apr 18 '11 at 20:46
1

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.

Timbo
  • 4,505
  • 2
  • 26
  • 29
  • No this is my first ASP.NET app ever. So I wont have many users at all. I'm sure looking them up by UserName or UserID would be fine. I'm just trying to understand how its suppose to work. Thanks! – Eric Anastas Apr 18 '11 at 21:02
0

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.

Jim Bolla
  • 8,265
  • 36
  • 54
  • My concern was that if I start creating relationships to the SqlMembershipProvider tables I might end up breaking something. When setting the Fk did you also set a delete or update rule so that if a user is deleted all associated application information is deleted as well? – Eric Anastas Apr 18 '11 at 20:52