Почему базовый провайдер членства должен решать, стоит ли…?

Question

А) Почему при использовании шаблонов с Мастер создания пользователя контроль, делает в том числе Текстовое окно с ID=Электронная почта зависеть от того, будет ли CreateUserWizard.RequireEmail для свойства установлено значение true, но Текстовое окно с ID=Вопрос требуется только в том случае, если базовый поставщик членства требует вопроса о пароле?Другими словами, почему бы базовому провайдеру членства не решать, стоит ли Текстовое окно ( с идентификатором=электронная почта ) требуется?

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

спасибо

РЕДАКТИРОВАТЬ:

А)

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

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

Б)

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

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

Answer 1

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

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

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

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

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

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

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

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

Answer 2

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

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

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

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

---

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

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

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

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