A) 为什么在使用带有 CreateUserWizard 控件的模板时，包含带有 ID=Email 的 Textbox 取决于是否 CreateUserWizard. RequireEmail 属性设置为 true，但仅当底层会员资格提供程序需要密码问题时，才需要带有 ID=Question 的 TextBox？
换句话说，为什么不由底层会员资格提供商来决定是否需要 Textbox （ with ID=email ）？
B) 另一方面，为什么要由会员提供商来决定是否需要密码问题？ 这难道不应该由会员级别来决定吗？ 毕竟，会员提供者的工作应该只是提供对底层数据存储的访问，而不是决定用户必须提供哪些数据？！
感谢
编辑：
A）
归根结底，会员资格提供商有一个明显的映射：RequiresQuestionAndAnswer，您可以设置并强制执行此映射，但您不能指定用户必须提供电子邮件地址。
那么 RequiresUniqueEmail 本质上告诉用户不必指定电子邮件地址，但如果她这样做，它必须是唯一的？
B)
A) Why, when using templates with CreateUserWizard control, does including Textbox with ID=Email depend on whether CreateUserWizard.RequireEmail property is set to true, but TextBox with ID=Question is required only if underlying membership provider requires password question?
In other words, why wouldn’t it also be up to underlying membership provider to decide whether Textbox ( with ID=email ) is required?
B) On the other hand, why would be up to membership provider to decide whether password question is required? Shouldn’t this be up to Membership class to decide? Afterall, the job of membership provider should just be to provide access to underlying data store, and not to decide what data users must provide?!
thanx
EDIT:
A)
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.
So RequiresUniqueEmail in essence tells that user doesn’t have to specify an email address, but if she does, it must be unique?
B)
-
If I understand membership providers correctly, they are the entities that send SQL queries to data storage?! Thus I assume they have full knowledge of tables and relationships etc this data storage has?
-
But still, what if data storage doesn’t have a column for storing email addresses, but CreateUser() specifies email address as one of its parameters? How does membership provider handle that?
发布评论
评论（2）
有趣的是，电子邮件是预期数据字段的一部分。
让我澄清一下...如果您将 SQL 提供程序的 RequiresUniqueEmail 设置为 true，则严格来说，将不需要电子邮件。 这只是意味着每个用户都必须使用与其他用户不同的电子邮件地址。 因此，可能有一个用户没有电子邮件地址。 将在数据库中设置空值。 但此后没有其他用户能够省略电子邮件地址，因为这会导致两个用户的电子邮件为空......因此从功能上讲，它可能与所需的电子邮件地址相同，但在技术上并不相同。
向导控件提供了一个用于收集成员资格信息的默认 UI，并且假定您将使用默认的 SQL 提供程序。 如果您不使用默认提供程序，您的提供程序不支持所有字段，或者您的提供程序中有其他独特的约束，那么您应该使用自己的模板自定义向导步骤并处理向导的事件以提供您自己的验证以及适当的附加逻辑。
至于理解Membership系统本身...
asp.net中的Membership系统是严格的OO设计和便利性之间的折衷。 特定 Membership 提供程序继承自的 MembershipProvider 基类中有一些假设是自以为是的。 事实上，电子邮件地址将成为会员数据的一部分，这是基础提供商做出的更自由的假设之一。
通过做出这种假设（在大多数环境中都是如此），会员系统能够以简单直观的方式公开与电子邮件地址相关的一些功能（例如通过电子邮件地址而不是用户名获取用户以及禁止多个帐户）使用相同的电子邮件地址）。 如果基类没有做出这样的假设，那么每次您想要在特定提供程序中处理电子邮件时，您都必须将引用强制转换为您在应用程序中使用的特定类型。 这很麻烦。
从纯粹的面向对象的角度来看，这些假设是令人不舒服的。 但是，您可以（许多成员资格提供者这样做）为基类中的方法和属性提供空实现（如果他们不使用它们）。
您会在角色提供程序中看到更多这种情况...例如，Windows 令牌角色提供程序有很多抛出 NotImplmentedException 的成员（令牌角色提供程序是 AD 的只读提供程序，因此所有属性集访问器都会抛出异常）。
It is an interesting point that email is part of the expected data fields.
Let me clarify... if you set RequiresUniqueEmail to true for the SQL Provider, the email will NOT be required --strictly speaking. It just means that every user will have to use a different email address from any other user. So there can be one user without an email address. A null value will be set in the database. But no other user would be able to omit the email address after that because that would cause two users to have null emails... So functionally it may as well be the same as required email addresses, but it is not technically the same.
The wizard controls provide a default UI for collecting membership information, and it assumes you use will be using the default SQL provider. If you are not using the default provider, your provider doesn't support all of the fields, or you have other unique constraints in your provider then you should customize the wizard steps with your own templates and handle the wizard's events to provide your own validations and additional logic as appropriate.
As for understanding the Membership system itself...
The Membership system in asp.net is a compromise between strict OO design and convenience. There are a few assumptions in the base MembershipProvider class from which the specific Membership providers inherit that are presumptuous. The fact that email addresses will be part of the membership data in one of the more liberal assumptions the base provider makes.
By making that assumption though, which is true in most environments, the membership system is able to expose some functionality related to email addresses in a simple and intuitive way (such as getting a user by their email address instead of user name and prohibiting multiple accounts with the same email address). If the base class didn't make that assumption, then every time you wanted to do stuff with emails in your specific provider, you'd have to cast the reference to the specific type you are using within your application. This is cumbersome.
From a purely OO point of view, these assumptions are uncomfortable. But you can, and many membership providers do, provide empty implementations for methods and properties from the base class if they don't use them.
You see this more with role providers... for example the Windows Token Role provider has a lot of members that throw NotImplmentedException (the Token role provider is a read-only provider for AD, so all of the property set accessors throw exceptions).
归根结底，成员资格提供程序具有明显的映射： RequiresQuestionAndAnswer，您可以设置并强制执行此操作，但您无法指定用户必须提供电子邮件地址。
指定他们必须提供唯一的电子邮件地址 RequiresUniqueEmail 与“需要电子邮件”不同 - 因此 CreateUserWizard 为您提供了“我不在乎电子邮件地址是否唯一，只要有一个”的选项。
至于为什么会员资格提供者应该控制是否需要提问：这是因为提供者还控制诸如 EnablePasswordReset 和 EnablePasswordRetrieval 之类的东西 - 这些是会员资格类不知道的事情 - 事实上，即使会员资格类别有一个“ ValidateUser" 方法，它将使用 web.config 中指定的默认提供程序来执行此操作：
回应问题编辑
： 这是正确的，正如 Stephen 指出的，您可能有一个用户的电子邮件地址为空，然后所有其他用户都必须有一个值。 根据您的验证器，这实际上不必是有效的电子邮件地址。
b.1. 不完全是 - 提供程序向您的用户数据存储发送数据或从您的用户数据存储发送数据 - 这可能是 SQL，但也可能是 Active Directory、LDAP、文本文件等，但是是的，您的提供程序充当您的应用程序和应用程序之间的隔离层您的用户商店。
b.2. 会员资格有很多部分 - 有关实现自定义会员资格用户 带您完成创建自定义用户所需的步骤 - 如果您的数据存储无法处理电子邮件地址（或者您希望在配置文件中存储多封电子邮件），那么您的提供商可能会忽略创建或发送给您的任何值更新，并在获取时用 null 填充它。
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.
Specifying that they must supply a unique email address with RequiresUniqueEmail is not the same as saying "requires an email" - so the CreateUserWizard is offering you the option of saying "I don't care that the email addresses aren't unique, just that there is one".
As to why the membership provider should control whether a question is required: It's because the provider is also controlling things like EnablePasswordReset and EnablePasswordRetrieval - these are things that the memebership class has no knowledge of - in fact, even though the membership class has a "ValidateUser" method, it will use the default provider specified in the web.config to do this:
In response to question edits:
a. That is correct, as Stephen points out, you could have one user with an empty email address, and then all others would have to have a value. Depending on your validators, this doesn't actually have to be a valid email addres.
b.1. Not quite - The providers send data to and from your user data store - this might be SQL, but it could also be Active Directory, LDAP, a text file, etc, but yes, your provider acts as the seperation layer between your application and your user store.
b.2. There are many parts to membership - the documentation on implementing a custom Membership User takes you through the steps needed to create a custom user - if your data storage didn't handle email addresses (or you wanted multiple emails stored in a profile), then your provider could just ignore any value sent through to you on create or update, and populate it with null on get.