p2p.wrox.com Forums

p2p.wrox.com Forums (http://p2p.wrox.com/index.php)
-   BOOK: ASP.NET 2.0 Website Programming Problem Design Solution ISBN: 978-0-7645-8464-0 (http://p2p.wrox.com/forumdisplay.php?f=264)
-   -   Custom Membership Provider (http://p2p.wrox.com/showthread.php?t=69806)

Scott663 August 1st, 2008 01:56 PM

Custom Membership Provider
The built in Membership provider seems overly complicated and somewhat cumbersome to me, at least for my single TBH website project. For instance, the way in which profile properties are added via winconfig declarations, and saved to the DB as a concatenated string value is inefficient and unintuitive.

I've been contemplating rolling my own membership class and data tables, but wanted to know if any of you have attempted this already, and what advice you would offer. I'm not sure if extending the built in Membership with custom providers is the way to go, or if I should just do all user related work (i.e.: login, security, roles, etc...) myself.

One advantage I see is being able to use an identity field for foreign key references rather than the username. This should also allow me to safely cache larger amounts of data as well.

Any advice you can offer is greatly appreciated - Scott.

Lee Dumond August 1st, 2008 03:09 PM

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:


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.

Scott663 August 1st, 2008 04:33 PM

Lee, thanks for the excellent info. I've been using the Membership provider for a while now, but never took the time to fully understand it until now. I did not realize the user table had an identity field, but now I see the "ProviderUserKey" property. All the examples I've studied (including TBH) always used the username as a reference key, instead of the UserKey.

My comment about caching was not about caching the Membership data itself, but the fact that when I cache other data (forums, ratings, etc...) it seemed like a waste of recources to use reference key fields populated with usernames (~256kb) as opposed to an identity field (4kb). I hope this makes sense now?

Thanks for the link to Scott Guthrie's blog. His blogs are always excellent, and this article seems to address what I'm trying to do.

As far as understanding why the profile is serialized, I just figured it was so that developers could easily add custom profile properties without touching the DB and Membership entity. This is only a guess thought, which means I'm probably wrong...

Thanks again for your valuable input!

Lee Dumond August 1st, 2008 04:59 PM

Okay, you seem to have to down. :D

As for the caching, I don't think it would be difficult to use the identity field with the default providers if that's what you want to do.

Scott663 August 1st, 2008 05:16 PM

Agreed. Thanks for the help.

All times are GMT -4. The time now is 08:27 PM.

Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
© 2013 John Wiley & Sons, Inc.