View Single Post
  #2 (permalink)  
Old August 1st, 2008, 03:09 PM
Lee Dumond's Avatar
Lee Dumond Lee Dumond is offline
Wrox Author
Points: 4,942, Level: 29
Points: 4,942, Level: 29 Points: 4,942, Level: 29 Points: 4,942, Level: 29
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jan 2008
Location: Decatur, IL, USA.
Posts: 923
Thanks: 12
Thanked 166 Times in 162 Posts
Default

Off the top of my head, the only reason I can think of for developing a custom provider for the built-in Membership functionality is to marry this built-in functionality with an different database schema. For example, if instead of starting from scratch, you needed to tie into an existing database that already holds your member data.

Your real issue, it seems to me, is that you don't care for the way ASP.NET serializes profile objects. You do understand exactly why ASP.NET has to serialize the profile, right? If so, then you realize that developing a custom membership provider doesn't address this at all.

If sounds like what you want to do is to implement a custom profile provider. Scott Guthrie blogged about this here:

http://weblogs.asp.net/scottgu/archi...10/435038.aspx

This is a provider that works against your own custom Profile data store, issuing SQL directly against your tables or invoking your own custom SPROCS. That way, you would not have to use the built-in serialization.

So, that's what you need to do. That being said, I would comment further by expressing some confusion about the last part of your post. The built-in profile provider already uses an identity field, and caching the profile is not an issue under the built-in provider. Again, the main reason I can think of for a custom provider is that you need to interface with an existing incompatible schema. Otherwise, I guess I don't see the advantage to be gained by doing it.

Either way, good luck with it.