Wrox Programmer Forums
|
BOOK: ASP.NET 2.0 Website Programming Problem Design Solution ISBN: 978-0-7645-8464-0
This is the forum to discuss the Wrox book ASP.NET 2.0 Website Programming: Problem - Design - Solution by Marco Bellinaso; ISBN: 9780764584640
Welcome to the p2p.wrox.com Forums.

You are currently viewing the BOOK: ASP.NET 2.0 Website Programming Problem Design Solution ISBN: 978-0-7645-8464-0 section of the Wrox Programmer to Programmer discussions. This is a community of software programmers and website developers including Wrox book authors and readers. New member registration was closed in 2019. New posts were shut off and the site was archived into this static format as of October 1, 2020. If you require technical support for a Wrox book please contact http://hub.wiley.com
 
Old August 1st, 2008, 01:56 PM
Authorized User
 
Join Date: Mar 2007
Posts: 39
Thanks: 0
Thanked 1 Time in 1 Post
Default 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.

 
Old August 1st, 2008, 03:09 PM
Lee Dumond's Avatar
Wrox Author
 
Join Date: Jan 2008
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.
 
Old August 1st, 2008, 04:33 PM
Authorized User
 
Join Date: Mar 2007
Posts: 39
Thanks: 0
Thanked 1 Time in 1 Post
Default

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!


 
Old August 1st, 2008, 04:59 PM
Lee Dumond's Avatar
Wrox Author
 
Join Date: Jan 2008
Posts: 923
Thanks: 12
Thanked 166 Times in 162 Posts
Default

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.

 
Old August 1st, 2008, 05:16 PM
Authorized User
 
Join Date: Mar 2007
Posts: 39
Thanks: 0
Thanked 1 Time in 1 Post
Default

Agreed. Thanks for the help.






Similar Threads
Thread Thread Starter Forum Replies Last Post
Custom Membership provider question aspcoder BOOK: Beginning ASP.NET 3.5 : in C# and VB BOOK ISBN: 978-0-470-18759-3 3 July 27th, 2008 09:59 AM
Custom Membership Provider kulkarnimonica ASP.NET 2.0 Professional 0 June 21st, 2007 03:56 PM
problem with custom membership provider hertendreef ASP.NET 2.0 Professional 8 April 17th, 2007 12:11 PM
Issue with custom membership provider cacaldo ASP.NET 2.0 Professional 1 October 7th, 2006 03:05 AM
custom membership provider msrnivas General .NET 1 September 18th, 2005 04:28 AM





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