Pourquoi le fournisseur d’appartenance sous-jacent devrait-il décider si & # 8230 ;?

Question

A) Pourquoi, lors de l'utilisation de modèles avec le contrôle CreateUserWizard , l'inclusion de Zone de texte avec ID = Email dépend de si CreateUserWizard. La propriété RequireEmail est définie sur true, mais TextBox avec ID = Question est requis uniquement si le fournisseur d'appartenance sous-jacent requiert un mot de passe? Autrement dit, pourquoi le fournisseur d’appartenance sous-jacent ne devrait-il pas également décider si Textbox ( avec ID = email ) est requis?

B) Par ailleurs, pourquoi le fournisseur d’appartenance devrait-il décider si la question du mot de passe est requise? Cela ne devrait-il pas incomber à la classe d'adhésion de décider? Après tout, le travail du fournisseur d’appartenance devrait simplement consister à fournir un accès au magasin de données sous-jacent et non à décider des données que les utilisateurs doivent fournir?!

merci

EDIT:

A)

  

Cela revient au fait que le fournisseur d'appartenance dispose d'un mappage évident: RequiertQuestionAndAnswer, que vous pouvez définir et faire appliquer, mais vous ne pouvez pas spécifier que l'utilisateur doit fournir une adresse électronique.

Donc, EssentialsUniqueEmail indique en substance à l’utilisateur que l’utilisateur n’est pas obligé de spécifier une adresse e-mail, mais si elle le souhaite, elle doit être unique?

B)

• Si je comprends bien les fournisseurs d’appartenance, ce sont les entités qui envoient des requêtes SQL au stockage de données?! Donc, je suppose qu'ils ont une connaissance complète des tables et des relations, etc. que ce stockage de données a?

• Néanmoins, que se passe-t-il si le stockage de données n’a pas de colonne pour stocker les adresses e-mail, mais que CreateUser () spécifie une adresse e-mail parmi ses paramètres? Comment le fournisseur d'adhésion gère-t-il cela?

Answer 1

Il est intéressant de noter que le courrier électronique fait partie des champs de données attendus.

Permettez-moi de préciser ... si vous définissez RequisUniqueEmail sur true pour le fournisseur SQL, le courrier électronique ne sera PAS requis - à proprement parler. Cela signifie simplement que chaque utilisateur devra utiliser une adresse électronique différente de celle de tout autre utilisateur. Donc, il peut y avoir un utilisateur sans adresse email. Une valeur nulle sera définie dans la base de données. Mais aucun autre utilisateur ne serait capable d'omettre l'adresse e-mail après cela car cela aurait pour conséquence que deux utilisateurs auront des e-mails nuls ... Donc, sur le plan fonctionnel, il peut aussi bien s'agir des adresses e-mail requises, mais ce n'est techniquement pas le même. / p>

Les contrôles de l'assistant fournissent une interface utilisateur par défaut pour la collecte des informations sur les membres, et supposent que vous utilisiez le fournisseur SQL par défaut. Si vous n'utilisez pas le fournisseur par défaut, si votre fournisseur ne prend pas en charge tous les champs ou si vous avez d'autres contraintes uniques, vous devez personnaliser les étapes de l'assistant avec vos propres modèles et gérer les événements de l'assistant pour fournir vos propres validations. et une logique supplémentaire, le cas échéant.

Pour ce qui est de comprendre le système d'adhésion lui-même ...

Le système d’adhésion sur asp.net est un compromis entre conception stricte et facilité d’utilisation. Il existe quelques hypothèses dans la classe de base MembershipProvider dont héritent les fournisseurs d'adhésion spécifiques et qui sont présomptueuses. Le fait que les adresses électroniques fassent partie des données sur les membres dans l’une des hypothèses les plus libérales du fournisseur de base.

En prenant cette hypothèse cependant, ce qui est vrai dans la plupart des environnements, le système d’adhésion est capable d’exposer certaines fonctionnalités liées aux adresses e-mail de manière simple et intuitive (comme obtenir un utilisateur par son adresse e-mail plutôt que par son nom interdire plusieurs comptes avec la même adresse e-mail). Si la classe de base ne fait pas cette hypothèse, chaque fois que vous souhaitez créer des éléments d'e-mails dans votre fournisseur spécifique, vous devez transtyper la référence sur le type spécifique que vous utilisez dans votre application. C'est lourd.

D'un point de vue purement OO, ces hypothèses sont inconfortables. Mais vous pouvez, et de nombreux fournisseurs d’adhésion le font, fournir des implémentations vides pour les méthodes et les propriétés de la classe de base s’ils ne les utilisent pas.

Vous le voyez plus souvent avec les fournisseurs de rôles ... Par exemple, le fournisseur de rôles Windows Token compte de nombreux membres qui lancent une exception NotImplmentedException (le fournisseur de rôles Token est un fournisseur en lecture seule pour AD, de sorte que tous les exceptions).

Answer 2

Cela revient au fait que le fournisseur d'appartenance dispose d'un mappage évident: NécessiteQuestionAndAnswer , que vous pouvez définir et faire appliquer, mais vous ne pouvez pas spécifier que l'utilisateur doit fournir une adresse électronique.

Spécifiant qu'ils doivent fournir une adresse électronique unique avec requiertUniqueEmail n’est pas la même chose que dire " nécessite un email " - Donc, CreateUserWizard vous offre la possibilité de dire: "Peu m'importe que les adresses électroniques ne soient pas uniques, mais qu'il en existe un".

Pourquoi le fournisseur d'appartenance doit-il contrôler si une question est requise? C'est parce qu'il contrôle également des choses comme EnablePasswordReset et EnablePasswordRetrieval. Ce sont des choses que la classe memebership n'a pas connaissance. En fait, même si la classe d'appartenance a un " ValidateUser ; Pour utiliser cette méthode, le fournisseur par défaut spécifié dans le fichier web.config:

  

La classe d'appartenance dépend des fournisseurs d'appartenance pour communiquer avec une source de données.

En réponse aux questions posées:

a. C’est exact, comme , indique Stephen, pourrait avoir un utilisateur avec une adresse e-mail vide, puis tous les autres devraient avoir une valeur. Selon vos validateurs, il n'est pas nécessaire que cette adresse soit valide.

b.1. Pas tout à fait. Les fournisseurs envoient des données vers et à partir de votre magasin de données utilisateur. Il s’agit peut-être de SQL, mais également d’Active Directory, de LDAP, d’un fichier texte, etc. Oui, votre fournisseur sert de couche de séparation entre votre application et votre magasin utilisateur.

b.2. Les membres sont nombreux: la documentation sur la implémentation d'un utilisateur d'appartenance personnalisé vous guide à travers les étapes nécessaires à la création d'un utilisateur personnalisé - si votre stockage de données ne gérait pas les adresses électroniques (ou si vous vouliez stocker plusieurs emails dans un profil), votre fournisseur pourrait alors ignorer toute valeur qui vous serait transmise lors de la création ou de la création. mettez à jour et remplissez-le avec null lors de l'obtention.