¿Por qué el proveedor de membresía subyacente debe decidir si & # 8230 ;?

Question

A) Por qué, cuando se usan plantillas con el control CreateUserWizard , incluir Textbox con ID = Email depende de si CreateUserWizard. La propiedad RequireEmail se establece en true, pero TextBox con ID = Question solo se requiere si el proveedor de membresía subyacente requiere una pregunta de contraseña. En otras palabras, ¿por qué no sería también del proveedor de membresía subyacente decidir si se requiere Textbox ( with ID = email )?

B) Por otra parte, ¿por qué dependería del proveedor de membresía para decidir si se requiere una pregunta de contraseña? ¿No debería & # 8217; t estar en clase de membresía para decidir? ¡Después de todo, el trabajo del proveedor de membresía debería ser simplemente proporcionar acceso al almacén de datos subyacente, y no decidir qué datos deben proporcionar los usuarios ?!

thanx

EDIT:

A)

  

Todo se reduce al hecho de que el proveedor de membresía tiene una asignación obvia: Requiere Pregunta y Respuesta, que puede establecer y hacer que se cumpla, pero no puede especificar que el usuario debe proporcionar una dirección de correo electrónico.

Entonces, ¿Exige UniqueEmail en esencia dice que el usuario no tiene que especificar una dirección de correo electrónico, pero si lo hace, debe ser único?

B)

• ¡Si entiendo correctamente a los proveedores de membresía, ¿son las entidades que envían consultas SQL al almacenamiento de datos? Entonces, ¿asumo que tienen un conocimiento completo de las tablas y relaciones, etc. que tiene este almacenamiento de datos?

• Pero aún así, ¿qué pasa si el almacenamiento de datos no tiene una columna para almacenar direcciones de correo electrónico, pero CreateUser () especifica la dirección de correo electrónico como uno de sus parámetros? ¿Cómo maneja eso el proveedor de membresía?

Answer 1

Es un punto interesante que el correo electrónico es parte de los campos de datos esperados.

Permítame aclarar ... si configura el requisito de UniqueEmail como verdadero para el proveedor de SQL, NO se requerirá el correo electrónico, hablando estrictamente. Solo significa que cada usuario tendrá que usar una dirección de correo electrónico diferente a la de cualquier otro usuario. Así que puede haber un usuario sin una dirección de correo electrónico. Se establecerá un valor nulo en la base de datos. Pero ningún otro usuario podría omitir la dirección de correo electrónico después de eso porque eso causaría que dos usuarios tuvieran correos electrónicos nulos ... Entonces, funcionalmente, puede ser lo mismo que las direcciones de correo electrónico requeridas, pero técnicamente no es lo mismo. / p>

Los controles del asistente proporcionan una IU predeterminada para recopilar información de membresía y se supone que usted usará el proveedor de SQL predeterminado. Si no está utilizando el proveedor predeterminado, su proveedor no es compatible con todos los campos, o tiene otras restricciones únicas en su proveedor, entonces debe personalizar los pasos del asistente con sus propias plantillas y manejar los eventos del asistente para proporcionar sus propias validaciones. y lógica adicional según corresponda.

En cuanto a la comprensión del propio sistema de Membresía ...

El sistema de Membresía en asp.net es un compromiso entre el diseño estricto de OO y la conveniencia. Hay algunos supuestos en la clase base MembershipProvider de los cuales heredan los proveedores de Membresía específicos que son presuntuosos. El hecho de que las direcciones de correo electrónico formarán parte de los datos de membresía en una de las suposiciones más liberales que hace el proveedor base.

Sin embargo, al hacer esa suposición, lo cual es cierto en la mayoría de los entornos, el sistema de membresía puede exponer algunas funcionalidades relacionadas con las direcciones de correo electrónico de una manera sencilla e intuitiva (como obtener un usuario por su dirección de correo electrónico en lugar del nombre de usuario y prohibiendo múltiples cuentas con la misma dirección de correo electrónico). Si la clase base no hizo esa suposición, entonces cada vez que quisiera hacer cosas con correos electrónicos en su proveedor específico, tendría que convertir la referencia al tipo específico que está usando dentro de su aplicación. Esto es engorroso.

Desde un punto de vista puramente OO, estas suposiciones son incómodas. Pero puede, y muchos proveedores de membresía, proporcionar implementaciones vacías para métodos y propiedades de la clase base si no las usan.

Esto se ve más con los proveedores de roles ... por ejemplo, el proveedor del rol de token de Windows tiene muchos miembros que emiten NotImplmentedException (el proveedor del rol de token es un proveedor de solo lectura para AD, por lo que todos los accesores de conjuntos de propiedades arrojan excepciones).

Answer 2

Todo se reduce al hecho de que el proveedor de membresía tiene una asignación obvia: RequiereQuestionAndAnswer , que puede configurar y hacer cumplir, pero no puede especificar que el usuario debe proporcionar una dirección de correo electrónico.

Especificando que deben proporcionar una dirección de correo electrónico única con RequiereUniqueEmail no es lo mismo que decir que " requiere un correo electrónico " - por lo tanto, el CreateUserWizard le ofrece la opción de decir "no me importa que las direcciones de correo electrónico no sean únicas, solo que hay una".

En cuanto a por qué el proveedor de membresía debe controlar si se requiere una pregunta: es porque el proveedor también está controlando cosas como EnablePasswordReset y EnablePasswordRetrieval - estas son cosas que la clase de membresía no tiene conocimiento, de hecho, aunque la clase de membresía tiene un " ValidateUser " ; método, utilizará el proveedor predeterminado especificado en web.config para hacer esto:

  

La clase Membership se basa en proveedores de membresía para comunicarse con una fuente de datos.

---

En respuesta a las ediciones de la pregunta:

a. Eso es correcto, como Stephen señala , usted podría tener un usuario con una dirección de correo electrónico vacía, y luego todos los demás tendrían que tener un valor. Dependiendo de sus validadores, esto no tiene por qué ser una dirección de correo electrónico válida.

b.1. No exactamente. Los proveedores envían datos desde y hacia su almacén de datos de usuario. Esto podría ser SQL, pero también podría ser Active Directory, LDAP, un archivo de texto, etc. Pero sí, su proveedor actúa como la capa de separación entre su aplicación y tu almacén de usuarios.

b.2. La membresía tiene muchas partes: la documentación en implementando un Usuario de Membresía personalizado lo lleva a través de los pasos necesarios para crear un usuario personalizado; si su almacenamiento de datos no maneja las direcciones de correo electrónico (o si desea múltiples correos electrónicos almacenados en un perfil), entonces su proveedor podría simplemente ignorar cualquier valor que se le envíe al crear o actualice y rellénelo con un valor nulo al obtener.