我试图理解在自定义类中继承Membership提供程序并重写它以实现自己的自定义提供程序的意义。
当会员资格提供商一开始就很糟糕时，这有什么好处！
我正试图弄清楚，当你可以自己滚动时，为什么人们会从提供者那里继承。即使覆盖了成员资格提供程序类，也必须创建逻辑。另外，如果我要创建自己的提供程序，如果我一开始就不喜欢，我不一定想为我的方法签名或该提供程序的方法数建模。
是的，内置的Membership提供程序很糟糕（我不得不自己重写它，用于性能和可扩展性都很重要的大型站点）。
使用它的优点是它很容易，文档也很好，网上有很多例子。
从标准实现继承的要点是，只需更改一些事情的工作方式就很容易了。如果你要从头开始重写，那么我会跳过继承（这就是我所做的）。
您可以覆盖成员资格提供程序，这样您就可以使用它的membership API。这对许多用途都很有用。例如，如果你试图将许多第三方网络论坛集成到你的应用程序中，它们需要使用会员API。
我不明白人们对API会员的缺失是什么。会员资格并不是让你的用户有名字、姓氏、地址或其他信息。它严格意义上是验证登录凭据，并提供基于角色的安全性。就是这样。
当您想添加其他字段时，您可以在自己的表中添加，并使您的成员ProviderUserKey成为表中的查找值。
主要优点是成员资格提供程序只需使用所有"开箱即用"的asp.net功能。像Forms Authentication、SiteMapProviders等都是为了与asp.net成员资格提供商很好地合作而设计的，所以通常情况下，与其说提供商本身是关键，不如说是依赖于提供商的东西让它在重新实现时变得有价值。
话虽如此，这并不意味着会员服务提供商将适合您的情况，因为您可能没有使用任何依赖它的组件，在这种情况下，实现它没有多大意义，因此您最好编写适合您需求的自己的会员模式。