问题
I can't understand why many people talk about creating membership provider that inherit from some base class in the asp.net library and registering the provider in the web.config file. Because we can get anything we want without doing this. I have written a static class that can check if a user exists with a corresponding database, add users, authenticate users by calling FormsAuthentication.SetAuthCookie and everything works. Shortly, Why we need to tell web.config file which provider we use. Why Our provider need to inherit Membership Provider ?
回答1:
Why we need to tell web.config file which provider we use.
Because that's how the provider model works in ASP.NET. If you write a custom provider you need to register it in web.config. You also need to indicate which is the default provider that your application will use. The same is true for the Role provider as well.
Our provider need to inherit Membership Provider ?
No, you are not required to do that. You could have a completely custom code that will perform the tasks of a membership provider such as verifying the credentials of a user or creating a new user.
The membership provider is just a standard way of performing those tasks in ASP.NET applications that most developers are familiar with. If you decide to roll your own custom code then if a new developer joins your team he will need to learn about all this custom code.
Also you mentioned that you wrote a static class. The drawback of static classes for those kind of things is that you are strongly coupling the different layers of your application making it difficult to test and reuse them in isolation. The whole point of the membership provider is that it is an abstraction. Also if you do not need all the functionality you don't need to override all the methods when writing a custom membership provider. Only those that you are actually using.
来源：https://stackoverflow.com/questions/14913271/why-using-telling-net-about-provider