asp.net - 为什么底层成员(member)提供商要决定是否……？

Question

A) 为什么，当使用带有 CreateUserWizard 控件的模板时，包含 ID=Email 的 Textbox 是否取决于 CreateUserWizard.RequireEmail 属性是否设置为 true，但仅当底层成员资格提供程序需要密码问题时才需要 ID=Question 的 TextBox？
换句话说，为什么不也由底层成员资格提供商决定是否需要 Textbox(ID=email)？

B) 另一方面，为什么要由成员(member)提供者决定是否需要密码问题？这不应该由 Membership 类来决定吗？毕竟，成员(member)提供者的工作应该只是提供对底层数据存储的访问，而不是决定用户必须提供哪些数据？!

谢谢

编辑:

一种)

It comes down to the fact that the membership provider has an obvious mapping: RequiresQuestionAndAnswer, which you can set and have this enforced, but you can't specify that the user must supply an email address.

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

乙)

如果我正确理解成员资格提供程序，它们就是将 SQL 查询发送到数据存储的实体？!因此，我假设他们对这个数据存储所具有的表和关系等有充分的了解？

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

Answer 1

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

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

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

至于了解成员(member)制度本身……

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

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

从纯粹的面向对象的角度来看，这些假设是不舒服的。但是，如果基类中的方法和属性不使用它们，您可以(并且许多成员资格提供者都这样做)为它们提供空的实现。

您在角色提供程序中看到的更多……例如，Windows token 角色提供程序有很多成员会抛出 NotImplmentedException( token 角色提供程序是 AD 的只读提供程序，因此所有属性集访问器都会抛出异常)。