Perché il fornitore di appartenenza sottostante dovrebbe decidere se ...?

Question

A) Perché, quando si utilizzano modelli con il controllo CreateUserWizard , l'inclusione di Casella di testo con ID = Email dipende dal fatto che CreateUserWizard. La proprietà RequireEmail è impostata su true, ma TextBox con ID = domanda è richiesto solo se il provider di appartenenza sottostante richiede una domanda con password? In altre parole, perché non spetterebbe anche al fornitore di appartenenza sottostante decidere se Casella di testo ( con ID = email ) è richiesto?

B) D'altra parte, perché spetterebbe al provider di appartenenza decidere se è richiesta la password? Non dovrebbe essere fino a Classe di appartenenza decidere? Dopotutto, il compito del provider di appartenenze dovrebbe essere semplicemente quello di fornire l'accesso all'archivio dati sottostante e non decidere quali dati devono fornire gli utenti ?!

Grazie

Modifica

A)

  

Dipende dal fatto che il provider di appartenenza ha una mappatura ovvia: richiedeQuestionAndAnswer, che puoi impostare e far applicare, ma non puoi specificare che l'utente deve fornire un indirizzo email.

Quindi richiede essenzialmenteUniqueEmail in sostanza dice che l'utente non deve specificare un indirizzo email, ma se lo fa, deve essere univoco?

B)

• Se capisco correttamente i provider di appartenenze, sono le entità che inviano query SQL all'archiviazione dei dati ?! Quindi presumo che abbiano una conoscenza completa delle tabelle e delle relazioni, ecc. Questa memoria dati ha?

• Ma cosa succede se l'archiviazione dei dati non ha una colonna per la memorizzazione degli indirizzi email, ma CreateUser () specifica l'indirizzo email come uno dei suoi parametri? Come lo gestisce il provider di appartenenze?

Answer 1

È interessante notare che la posta elettronica fa parte dei campi di dati previsti.

Permettetemi di chiarire ... se si imposta RichiedeUniqueEmail su true per il provider SQL, l'e-mail NON sarà richiesta - in senso stretto. Significa solo che ogni utente dovrà utilizzare un indirizzo e-mail diverso da qualsiasi altro utente. Quindi può esserci un utente senza un indirizzo email. Un valore null verrà impostato nel database. Ma nessun altro utente sarebbe in grado di omettere l'indirizzo e-mail perché ciò causerebbe due e-mail null in due utenti ... Quindi funzionalmente potrebbe anche essere lo stesso degli indirizzi e-mail richiesti, ma tecnicamente non è lo stesso.

I controlli della procedura guidata forniscono un'interfaccia utente predefinita per la raccolta delle informazioni sull'appartenenza e si presume che verrà utilizzato il provider SQL predefinito. Se non si utilizza il provider predefinito, il provider non supporta tutti i campi o si hanno altri vincoli univoci nel provider, è necessario personalizzare i passaggi della procedura guidata con i propri modelli e gestire gli eventi della procedura guidata per fornire le proprie convalide e logica aggiuntiva a seconda dei casi.

Per quanto riguarda la comprensione del sistema di appartenenza stesso ...

Il sistema di abbonamento in asp.net è un compromesso tra design OO rigoroso e praticità. Ci sono alcuni presupposti nella classe di appartenenza di base da cui i provider di appartenenza specifici ereditano presunti. Il fatto che gli indirizzi e-mail facciano parte dei dati di appartenenza in una delle ipotesi più liberali fatte dal fornitore di base.

Facendo questo presupposto, il che è vero nella maggior parte degli ambienti, il sistema di appartenenza è in grado di esporre alcune funzionalità relative agli indirizzi e-mail in modo semplice e intuitivo (come ottenere un utente tramite il proprio indirizzo e-mail anziché il nome utente e vietare più account con lo stesso indirizzo e-mail). Se la classe di base non ha assunto questo presupposto, ogni volta che volevi fare cose con le e-mail nel tuo provider specifico, dovresti trasmettere il riferimento al tipo specifico che stai utilizzando nella tua applicazione. Questo è ingombrante.

Da un punto di vista puramente OO, questi presupposti sono scomodi. Ma è possibile, e molti provider di appartenenza, fornire implementazioni vuote per metodi e proprietà della classe base se non li usano.

Lo vedi di più con i provider di ruoli ... ad esempio il provider di ruoli token di Windows ha molti membri che generano NotImplmentedException (il provider di ruoli token è un provider di sola lettura per AD, quindi tutti gli accessor del set di proprietà lanciano eccezioni).

Answer 2

Dipende dal fatto che il provider di appartenenze ha una mappatura ovvia: richiedeQuestionAndAnswer , che puoi impostare e far applicare, ma non puoi specificare che l'utente deve fornire un indirizzo email.

Specifica che devono fornire un indirizzo email univoco con RichiedeUniqueEmail non equivale a dire" richiede un messaggio di posta elettronica " - quindi CreateUserWizard ti offre la possibilità di dire " Non mi interessa che gli indirizzi email non siano univoci, solo che ce n'è uno " ;.

Il motivo per cui il provider di appartenenze dovrebbe controllare se è necessaria una domanda: è perché il provider controlla anche cose come EnablePasswordReset e EnablePasswordRetrieval - sono cose di cui la classe di memebership non è a conoscenza - in effetti, anche se la classe di appartenenza ha un " ValidateUser " ; metodo, utilizzerà il provider predefinito specificato in web.config per fare questo:

  

La classe di appartenenza si basa sui provider di appartenenza per comunicare con un'origine dati.

---

In risposta alle modifiche alle domande:

a. È corretto, come sottolinea Stephen , tu potrebbe avere un utente con un indirizzo e-mail vuoto e quindi tutti gli altri dovrebbero avere un valore. A seconda dei tuoi validatori, questo in realtà non deve essere un indirizzo email valido.

b.1. Non del tutto - I provider inviano dati da e verso il tuo archivio dati utente - questo potrebbe essere SQL, ma potrebbe anche essere Active Directory, LDAP, un file di testo, ecc., Ma sì, il tuo provider funge da livello di separazione tra l'applicazione e il tuo archivio utenti.

b.2. Vi sono molte parti dell'appartenenza: la documentazione su l'implementazione di un utente di abbonamento personalizzato ti guida attraverso i passaggi necessari per creare un utente personalizzato: se l'archiviazione dei dati non gestiva gli indirizzi e-mail (o se volevi più e-mail archiviate in un profilo), il tuo provider potrebbe semplicemente ignorare qualsiasi valore inviato tramite te al momento della creazione o aggiornare e popolarlo con null su get.