简体繁体 English

会员提供者

[英]Membership Provider

原文 2011-09-05 16:31:51 0 2 asp.net/ asp.net-membership

I am currently developing an web site using asp and have a few questions regarding Membership Provider. 我目前正在使用ASP开发一个网站，并且对会员资格提供者有一些疑问。

I am currently inheriting from Membership Provider class and have just got over the issue of only certain parameters being able to be passed to the CreateUser method. 我目前从Membership Provider类继承，并且刚刚解决了仅某些参数能够传递给CreateUser方法的问题。

I have been able to overcome this issue by creating a class that inherits from MembershipUser adding custom properties and then passing that the the UpdateUser method. 通过创建一个从MembershipUser继承的类并添加自定义属性，然后将其传递给UpdateUser方法，我已经能够解决此问题。 However to me this seems quite messy and not very efficient as I am making two calls to the database when I could do it in one if I dont use the CreateUserWizard. 但是对我来说，这似乎很混乱并且效率不高，因为如果不使用CreateUserWizard可以一次对数据库进行两次调用，那么我将对数据库进行两次调用。

So my question is, is using the Provided Login components worthwhile if you are overriding the methods and require more parameters ect in order to keep the use of the properties you can define for this class in the web.config file or is it easier in the long run to just start from scratch. 因此，我的问题是，如果您要覆盖方法并需要更多参数等，以便使用可以在web.config文件中为此类定义的属性，是否值得使用Provided Login组件？从长远来看只是从头开始。 Basically what I want to know is how people have found using Membership by overriding and inheritance over starting from scratch, and how these compare. 基本上，我想知道的是人们是如何通过从头开始重写和继承来使用会员身份的，以及它们之间的比较。

Any webpages that talk about this would be good and apologies if the question doesn't make sense or I have missed anything out. 如果问题没有道理或者我错过了任何内容，那么任何谈论此问题的网页都将是不错的选择，并对此表示歉意。

Thanks, 谢谢，

Ric 里克

2 个解决方案

如果我正确理解了您的问题，那么是的，成员资格提供程序是一个很好的构建基础，因此您不必为身份验证/授权的基础重新发明轮子。

You are using Membership wrong. 您使用的会员资格错误。 You should only create your own custom provider when you need to map onto an existing database. 仅当需要映射到现有数据库时，才应该创建自己的自定义提供程序。 IF you are making your own database, then you should just use the default implementation. 如果要创建自己的数据库，则应仅使用默认实现。

Even if you create a custom implementation, you should not do anything that the current membership doesn't already provide. 即使创建自定义实现，也不应执行当前成员资格尚未提供的任何操作。 Just map those functions on to your database. 只需将这些功能映射到您的数据库即可。

To add additional information, you create a secondary table called UserData or something. 要添加其他信息，请创建一个名为UserData或诸如此类的辅助表。 This table will be keyed by the MembershipUser.ProviderUserKey, so you lookup any data you need from the other table using the userid from the membership class. 该表将由MembershipUser.ProviderUserKey键入关键字，因此您可以使用成员资格类中的userid从另一个表中查找所需的任何数据。

You're really fighting upstream trying to change membership to give you custom things. 您实际上是在与上游进行斗争，试图更改成员资格以为您提供自定义功能。 You can do it, but why cause yourself trouble? 您可以做到，但是为什么会给自己带来麻烦呢？