Почему основной провайдер членства должен решать ...

Question

A) Почему при использовании шаблонов с элементом управления CreateUserWizard включение Textbox с ID = Email зависит от того, CreateUserWizard.RequireEmail свойство имеет значение true, но TextBox с ID = Вопрос требуется только в том случае, если основной поставщик членства требует пароля? Другими словами, почему бы не решить, требуется ли Textbox ( с ID = email ) базовым провайдером членства?

B) С другой стороны, с какой стати провайдер членства должен решить, требуется ли вопрос о пароле? Разве это не должно быть до Членского класса , чтобы решить? В конце концов, задача поставщика членства должна состоять в том, чтобы просто обеспечить доступ к базовому хранилищу данных, а не решать, какие данные должны предоставлять пользователи?!

1032 * спасибо *

EDIT:

A)

Это сводится к тому, что у поставщика членства есть очевидное сопоставление: requireQuestionAndAnswer, которое вы можете установить и применить это принудительно, но вы не можете указать, что пользователь должен предоставить адрес электронной почты.

Таким образом, RequireUniqueEmail по сути говорит, что пользователю не нужно указывать адрес электронной почты, но если он это делает, он должен быть уникальным?

B)

• Если я правильно понимаю провайдеров членства, они являются сущностями, которые отправляют SQL-запросы в хранилище данных ?! Таким образом, я предполагаю, что у них есть полное знание таблиц и отношений и т.д., что это хранилище данных имеет?

• Но все же, что если хранилище данных не имеет столбца для хранения адресов электронной почты, но CreateUser () указывает адрес электронной почты в качестве одного из своих параметров? Как провайдер членства справляется с этим?

Answer 1

Интересно, что электронная почта является частью ожидаемых полей данных.

Позвольте мне уточнить ... если вы установите для RequuniqueEmail значение true для поставщика SQL, электронная почта НЕ потребуется, строго говоря. Это просто означает, что каждому пользователю придется использовать адрес электронной почты, отличный от любого другого пользователя. Таким образом, может быть один пользователь без адреса электронной почты. В базе данных будет установлено нулевое значение. Но никакой другой пользователь не сможет опустить адрес электронной почты после этого, потому что это приведет к тому, что два пользователя будут иметь нулевые адреса электронной почты ... Так что функционально это может совпадать с требуемыми адресами электронной почты, но технически это не то же самое.

Элементы управления мастера предоставляют пользовательский интерфейс по умолчанию для сбора информации о членстве, и предполагается, что вы будете использовать поставщика SQL по умолчанию. Если вы не используете провайдера по умолчанию, ваш провайдер не поддерживает все поля или у вас есть другие уникальные ограничения в вашем провайдере, тогда вы должны настроить шаги мастера с помощью своих собственных шаблонов и обработать события мастера, чтобы обеспечить свои собственные проверки. и дополнительная логика в зависимости от обстоятельств.

Что касается понимания самой системы членства ...

Система членства в asp.net - это компромисс между строгим дизайном ОО и удобством. В базовом классе MembershipProvider есть несколько предположений, от которых наследуют конкретные поставщики членства, которые являются самонадеянными. Тот факт, что адреса электронной почты будут частью данных о членстве в одном из более либеральных допущений, которые делает базовый провайдер.

Делая это предположение, хотя это верно для большинства сред, система членства способна предоставить некоторые функции, связанные с адресами электронной почты, простым и интуитивно понятным способом (например, получить пользователя по его адресу электронной почты вместо имени пользователя и запрещение нескольких учетных записей с одним и тем же адресом электронной почты). Если базовый класс не делал этого предположения, то каждый раз, когда вы хотите что-то сделать с электронными письмами вашего конкретного провайдера, вам придется приводить ссылку на конкретный тип, который вы используете в своем приложении. Это громоздко.

С чисто ОО точки зрения эти предположения неудобны. Но вы можете, и многие поставщики членства предоставляют пустые реализации для методов и свойств из базового класса, если они их не используют.

Вы видите это больше с поставщиками ролей ... например, у поставщика ролей Windows Token есть много членов, которые выдают NotImplmentedException (поставщик ролей Token является поставщиком только для чтения для AD, поэтому все методы доступа набора свойств выбрасывают исключения).

Answer 2

Все сводится к тому, что у поставщика членства есть очевидное сопоставление: Требуется вопросAndAnswer , который вы можете установить и применить это принудительно, но вы не можете указать, что пользователь должен укажите адрес электронной почты.

Указание, что они должны предоставить уникальный адрес электронной почты с requireUniqueEmail - это не то же самое, что сказать «требуется электронная почта» - поэтому CreateUserWizard предлагает вам возможность сказать «Мне все равно, что адреса электронной почты не уникальны, просто есть один ".

Относительно того, почему провайдер членства должен контролировать, требуется ли вопрос: это потому, что провайдер также контролирует такие вещи, как EnablePasswordReset и EnablePasswordRetrieval - это вещи, о которых класс memebership не знает - фактически, хотя класс членства имеет метод " ValidateUser ", для этого он будет использовать поставщика по умолчанию, указанного в файле web.config:

Класс Membership использует провайдеров членства для связи с источником данных.

---

В ответ на редактирование вопроса:

а. Это правильно, поскольку Стивен указывает на , у вас может быть один пользователь с пустым адресом электронной почты, и тогда все остальные должны будут иметь значение. В зависимости от ваших валидаторов, это не обязательно должен быть действительный адрес электронной почты.

стр.1. Не совсем - провайдеры отправляют данные в и из вашего хранилища пользовательских данных - это может быть SQL, но это также может быть Active Directory, LDAP, текстовый файл и т. Д., Но да, ваш провайдер действует как уровень разделения между вашим приложением и Ваш пользовательский магазин.

б2. Членство состоит из множества частей - документация по реализации пользовательского членства проведет вас через шаги, необходимые для создания пользовательского пользователя - если ваше хранилище данных не обрабатывало адреса электронной почты (или вы хотели сохранить несколько электронных писем в профиле), тогда ваш провайдер может просто игнорировать любое значение, отправленное вам при создании или обновлении, и заполнять его нулем при получении.