为什么基础会员提供者决定是否......？

Question

A）为什么在使用 CreateUserWizard 控件的模板时， Textbox 包含 ID = Email 取决于 CreateUserWizard。 RequireEmail 属性设置为true，但仅当基础成员资格提供程序需要密码问题时才需要 TextBox ID = Question 吗？ 换句话说，为什么不能由底层会员提供商来决定是否需要 Textbox （ ID = email ）？

B）另一方面，为什么要由会员提供商决定是否需要密码问题？这不应该由会员级来决定吗？毕竟，会员提供者的工作应该是提供对底层数据存储的访问，而不是决定用户必须提供哪些数据？！

感谢名单

修改

A）

  

归结为成员资格提供者有一个明显的映射：RequiresQuestionAndAnswer，您可以设置并执行此操作，但您无法指定用户必须提供电子邮件地址。

所以RequiresUniqueEmail本质上告诉用户不必指定电子邮件地址，但如果她这样做，它必须是唯一的？

B）

• 如果我正确理解成员资格提供程序，它们是将SQL查询发送到数据存储的实体？！因此，我假设他们完全了解这个数据存储有哪些表和关系？

• 但是，如果数据存储没有用于存储电子邮件地址的列，但CreateUser（）将电子邮件地址指定为其参数之一，该怎么办？会员提供商如何处理？

Answer 1

有趣的是，电子邮件是预期数据字段的一部分。

让我澄清一下......如果您为SQL提供商设置RequiresUniqueEmail为true，则不需要电子邮件 - 严格来说。这只意味着每个用户都必须使用来自任何其他用户的不同电子邮件地址。因此，可以有一个没有电子邮件地址的用户。将在数据库中设置空值。但是之后没有其他用户可以省略电子邮件地址，因为这会导致两个用户拥有空电子邮件......所以从功能上来说它可能与所需的电子邮件地址相同，但技术上并不相同。 / p>

向导控件提供用于收集成员资格信息的默认UI，并假定您将使用默认SQL提供程序。如果您没有使用默认提供程序，您的提供程序不支持所有字段，或者您的提供程序中有其他唯一约束，那么您应该使用自己的模板自定义向导步骤并处理向导的事件以提供您自己的验证和适当的额外逻辑。

至于了解会员制度本身......

asp.net中的会员系统是严格的OO设计和便利之间的折衷。基础MembershipProvider类中有一些假设，特定的成员资格提供程序继承这些假设是冒昧的。事实上，电子邮件地址将成为基础提供商做出的更自由的假设之一的成员资格数据的一部分。

通过做出这样的假设，在大多数环境中都是如此，会员系统能够以简单直观的方式公开与电子邮件地址相关的一些功能（例如通过他们的电子邮件地址而不是用户名来获取用户和禁止使用相同电子邮件地址的多个帐户）。如果基类没有做出这样的假设，那么每次你想在特定的提供者中处理电子邮件时，你必须将引用转换为你在应用程序中使用的特定类型。这很麻烦。

从纯OO的角度来看，这些假设令人不舒服。但是，如果不使用它们，您可以和许多成员资格提供程序一起为基类提供方法和属性的空实现。

您可以通过角色提供程序看到更多内容...例如，Windows令牌角色提供程序有很多成员会抛出NotImplmentedException（令牌角色提供程序是AD的只读提供程序，因此所有属性集访问器都会抛出例外）。

Answer 2

归结为会员提供商有一个明显的映射：RequiresQuestionAndAnswer，您可以设置并强制执行此操作，但您无法指定用户必须提供电子邮件地址。

指定他们必须提供具有RequiresUniqueEmail的唯一电子邮件地址与说“需要电子邮件”不同 - 因此CreateUserWizard为您提供了“我不关心电子邮件地址”的选项不是唯一的，只是有一个“。

至于为什么会员提供者应该控制是否需要一个问题：这是因为提供者也在控制诸如EnablePasswordReset和EnablePasswordRetrieval之类的东西 - 这些是会员类不知道的东西 - 事实上，即使是会员级别有一个“ValidateUser”方法，它将使用web.config中指定的默认提供程序来执行此操作：

  

Membership类依赖于成员资格提供程序与数据源进行通信。

---

回答问题编辑：

一个。这是正确的，因为Stephen points out，您可以让一个用户使用空的电子邮件地址，然后所有其他用户必须拥有一个值。根据您的验证器，这实际上不必是有效的电子邮件地址。

B.1。不完全 - 提供者向用户数据存储发送数据或从用户数据存储发送数据 - 这可能是SQL，但它也可能是Active Directory，LDAP，文本文件等，但是，您的提供者充当您的应用程序和应用程序之间的分离层。你的用户商店。

B.2。成员资格有很多部分 - implementing a custom Membership User上的文档将指导您完成创建自定义用户所需的步骤 - 如果您的数据存储没有处理电子邮件地址（或者您希望在配置文件中存储多封电子邮件），那么您的提供商可以忽略在创建或更新时发送给您的任何值，并在get上填充null。