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

Question

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

Or do many people make the

Answer 1

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..

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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

Answer 6

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.