Overriding the ASP.NET Membership provider

1
votes

I'm trying to understand the point of inheriting the Membership provider in a custom class and overriding it to implement your own custom provider.

What's the benefit of this when the Membership provider sucks in the first place!

I'm trying to figure out why people are inheriting from the provider when you can just roll your own. You're gonna have to create the logic anyway even if you override the membership provider classes. Plus if I'm gonna create my own provider I'm not necessarily going to want to model my method signatures or # of methods by this provider if I don't like it in the first place.

3
asp.netasp.net-mvc
It may not meet your needs, but that doesn't mean it sucks. It works perfectly well for a majority of uses. – Erik Funkenbusch
ok most shops that are serious do not like it. Especial serious ecommerce shops. – PositiveGuy
How do you know? I've worked at 3 ecommerce shops, all of them use the Membership API. One of them is in the top 100 ecommerce sites list. – Erik Funkenbusch
because I said I don't like the GUIDs, the table structure, etc, so why bother even inheriting from it. It's just hokey, that's how I know, I've looked at it. It's not extensible in that it ties you to SQL Server first off. And like I said I hate Guids. – PositiveGuy
You really have NOT looked at it, because if you had you would know you are completely wrong. Membership API does NOT tie you to guids, nor does it tie you to SQL Server. ASP.NET even ships a membership provider for ActiveDirectory, and there are providers for MySQL, Oracle and others. I suggest you actually know what you're talking about before you insist you do. – Erik Funkenbusch

3 Answers

3
votes

Yes, the built-in Membership provider sucks (I've had to re-write it myself, for use with large-scale sites where performance and scalability are concerns).

The advantage of using it is that it's easy, reasonably well documented, with lots of examples on the web.

The point of inheriting from the standard implementation is that makes it easy to just change the way a few things work. If you're going to re-write it from scratch, then I would skip the inheritance (which is what I've done).

2
votes

You override the membership provider so that you can use the Membership API with it. This is useful for many purposes. For instance, if you're trying to integrate many third party web forums into your app, they require using the Membership API.

I fail to understand what people find so lacking in the membership API. Membership is not about having your users first and last names, or addresses or other information. It's strictly about validating login credentials, and providing role based security. That's it.

When you want to add other fields, you do so in your own tables, and make your membership ProviderUserKey a lookup value in your tables.

1
votes

The main advantage is that the membership provider just works with all the "out of the box" asp.net features. Things like Forms Authentication, SiteMapProviders etc are designed to work well with the asp.net membership provider so often it's not so much the provider itself that is the key, it's the things that depend on the provider that make it worth while re-implementing.

Having said that, this doesn't mean that the membership provider will be a suitable fit for your situation, as you may not be using any of the components that are dependent on it, in which case, it doesn't make much sense to implement it and therefore you would be much better off writing your own membership model that does suit your needs.