0

I'm confused in the proper time to use SQLMembershipProvider vs my own custom provider. I'm building a system where users can create accounts; and then create objects in our system. When a user logs in, he should be able to see and edit the objects that he created.

Now, can I do this by using the SQLMembershipProvider? My understanding is that SQLMembershipProvider stores the users in its own database. If this is the case, how can I associate my objects with the user that created them? I've read about the Profile Properties system, but it doesn't seem like that would work, as that just adds extra information, like a postal code, to the .Net users object.

What would my object table look like; as in what would the column that says which user created the object be?

Or, do I just have to create a custom MembershipProvider which stores the users in my own database?

GendoIkari
  • 11,734
  • 6
  • 62
  • 104

1 Answers1

0

All you need is for your object table to have a UserId column that's a foreign key to the User table that the SQLMembershipProvider creates.

Esteban Araya
  • 29,284
  • 24
  • 107
  • 141
  • I read in this other question that you can't easily get the userId field from the membership API: http://stackoverflow.com/questions/2530113/using-asp-net-sql-membership-provider-how-do-i-store-my-own-per-user-data – GendoIkari Sep 29 '11 at 16:05
  • Not sure why he's having problems. I've done this on multiple occasions. – Esteban Araya Sep 29 '11 at 16:08
  • How can I get the UserId of the currently logged in user? I don't see any UserId property on the MembershipUser type. I don't want to use the username property because the username could be changed. – GendoIkari Oct 03 '11 at 16:09
  • Ok, I got it from ProviderKey and cast it as a Guid... but that seems like a less than ideal solution because now if I switched to a provider other than SQL, the code would break when it tries the cast. – GendoIkari Oct 03 '11 at 17:15
  • @GendoIkari: If you switch to a provider that does not used a GUID as its primary key, you'll have bigger problems than your code breaking. All your relationships will also break. – Esteban Araya Oct 03 '11 at 21:00
  • I thought the whole point of the provider pattern was that your code shouldn't care how the memberships are stored; and you could just inject different MembershipProviders in as needed. But this seems to be working; thanks! – GendoIkari Oct 04 '11 at 15:30