问题描述
结果
A）为什么使用带有模板时的的CreateUserWizard 的控制，也包括的文本框的用的 ID =电子邮件的取决于是否的 CreateUserWizard控件。 RequireEmail 的属性被设置为true，但文本框的用的 ID =问题的只有当潜在的成员资格提供需要密码提示问题必需的？
换句话说，为什么不也达到底层成员提供，以决定是否文本框的（用ID =电子邮件的）是必需的？
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）。另一方面，为什么会高达成员提供，以决定是否需要密码的问题？不应该这样达到的 Membership类的决定？毕竟，会员供应商的工作应该仅仅是提供访问底层数据存储，而不是决定用户必须提供什么样的数据？！
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?!
结果
感谢名单
结果
编辑：
A）
它归结为一个事实，即成员提供有一个明显的映射：RequiresQuestionAndAnswer，您可以设置和这个强制执行，但你不能指定用户必须提供一个电子邮件地址
所以RequiresUniqueEmail在本质上告诉用户不必指定电子邮件地址，但如果她做，它必须是唯一的？
So RequiresUniqueEmail in essence tells that user doesn’t have to specify an email address, but if she does, it must be unique?
结果
B）
-
如果我理解正确的成员资格提供程序，它们是发送SQL查询的数据存储实体？因此，我认为他们有表和关系等这样的数据存储有充分的知识？
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?
但尽管如此，如果数据存储没有存储的电子邮件地址一栏，但CREATEUSER（）指定的电子邮件地址作为它的一个参数是什么？如何成员资格提供处理这个问题？
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?
推荐答案
这是一个有趣的一点，电子邮件是预期的数据字段的一部分。
It is an interesting point that email is part of the expected data fields.
让我澄清一下......如果你设置RequiresUniqueEmail为true SQL提供的电子邮件不会被要求--strictly讲话。它只是意味着每个用户必须从任何其他用户使用不同的电子邮件地址。因此，有可能是没有电子邮件地址的用户。 null值将在数据库中进行设置。但没有其他用户将能够之后省略的电子邮件地址，因为这会导致两个用户具有空邮件...因此在功能上它可能也是相同的要求的电子邮件地址，但它在技术上并不相同。
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.
该向导控制提供了一种收集会员信息的默认UI，并假定您使用将使用默认的SQL提供。如果你不使用默认的提供者，提供者不支持所有的字段，或者你有其他的唯一约束在您的供应商，那么你应该自定义向导步骤与自己的模板和处理向导的事件来提供自己的验证和其他逻辑为宜。
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...
在asp.net会员制度是严格的面向对象的设计和便利的妥协。有在基的MembershipProvider类是presumptuous几个假设从该具体的成员提供继承。该电子邮件地址将会员数据的一部分，在更宽松的假设基础，使供应商之一的事实。
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.
您看到更多的角色提供...例如在Windows标记角色提供有大量抛出NotImplmentedException成员国（标记角色提供是AD只读提供商，所以所有的属性集访问的抛例外）。
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).
这篇关于为什么要基本成员资格提供程序决定是否......？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！