Do most people use .NET's SqlMembershipProvider, SqlRoleProvider, and SqlProfileProvider?

9
votes

Do most people use .NET's SqlMembershipProvider, SqlRoleProvider, and SqlProfileProvider when developing a site with membership capabilities?

Or do many people make their own providers, or even their own membership systems entirely?

What are the limitations of the SQL providers that would make you roll your own?

Is it easy to extend the SQL providers to provide additional functionality?

For Reference
Per Scott Gu's Blog, Microsoft provides the source code for the SqlMembershipProvider so that you can customize it, instead of starting from scratch. Just an FYI.

7
c#asp.netsqlmembershipprovidersqlroleprovidersqlprofileprovider
Dude! The source to the built in providers. Awesome! There goes my day at work tomorrow :-) – Dan F
Haha yeah. I was pretty excited when I found it too. I was able to make this crazy system that dynamically sets the main connection string based on the current sub-domain. Normally, you need a default connection string. – John B
Following a link from Scott Gu's blog, I found some <a href='asp.net/downloads/sandbox/table-profile-provider-samples/… provider samples<a>. The table provider sample allows you to map properties to columns in the config, which makes writing queries for profiles much easier. – user6535

7 Answers

6
votes

We use everything except the Profile Provider. The Profile Provider is completly text based and does full text seearches - this becomes exceedingly slow as you user base gets larger. We have found it a much better solution to "role our own" profile section of the membership api database that is keyed to the userid in membership.

2
votes

I've rolled my own MembershipProvider classes using derived MembershipUser types to wrap the custom user schema, so profile-style properties are now available everywhere as part of the derived user via a cast.

1
votes

I normally use the providers that come out of the box, the main problem I have is querying across profile attributes across users. For example finding all users that have a profile attribute called Car that equals true. This is down to the way they are stored in the underlying structure.

1
votes

I've used SqlMembership before and it's quite nice, unless you need something custom. I remember needing something like firstname and lastname info and I realised there're no fields for that. In the end instead of extending I've used Comment field of the provider and added name info to there. This is probably a bad practice/lazy/hack way but it worked for me in a tight situation..

0
votes

In theory they sound nice, but not a chance if you do any unit testing without creating lots of abstract wrappers.

0
votes

If you only need the basic user support (roles, profiles, etc.) then the default providers will work great.

If you need more customized support (data storage in a database not supported by the default providers [like Oracle], provider on a database that already exists, a heavily customized schema) then you should roll your own providers.

As for me, my current site only needed basic Roles support (and minimal Profiles support), so I went with the default providers.

0
votes

I have used both the custom classes and built in. When you need to get to a different database or schema or need to have extra info.

I abstracted out the layers so that it would work on the logic layer and have a DAL layer that used the data.common.dbprovider bit so it was reasonably generic.