Membership.CreateUser() in una libreria di classi

Question

Sono in procinto di spostare il codice da App_Code in una libreria di classi.

Creare gli utenti a livello di programmazione utilizzando Membership.CreateUser.

Come posso continuare a farlo all'interno della mia libreria di classi in cui non è possibile accedere al provider di appartenenze che ho configurato in web.config?

Answer 1

Aggiungere una direttiva using allo spazio dei nomi System.Web.Security nella classe - questo vi darà accesso diretto alla classe Membership.

C#:

using System.Web.Security; 

VB.NET:

Imports System.Web.Security 

Answer 2

è possibile accedervi ovunque siccome la classe Membership è una rappresentazione statica del provider corrente impostato dal sistema fornitore di ASP.NET.

Answer 3

Ho risolto il problema copiando l'intero web.config sul mio file app.config. Stavo usando un'applicazione console. Pensavo di aver copiato le sezioni necessarie ma fino a quando non ho copiato tutto, i dati non arrivavano al database

Answer 4

Prima di mostrare come funziona la parte di codice, è necessario capire come le impostazioni vengono caricate in questo tipo di scenario .

Quando si dispone di un'applicazione Web che sta per caricare il file .dll - e che il file .dll sta per accedere al MembershipProvider quale la domanda è configurato - è necessario fare alcune ipotesi.

1. L'applicazione web ha un MembershipProvider
2. L'applicazione web fornisce le impostazioni per quella MembershipProvider nella sua Web.Config
3. Il Web Application carica il .dll correttamente

Poiché il file .dll dovrebbe essere incluso nel nella directory /bin dell'applicazione Web, dovresti essere in grado di fare affidamento sulla configurazione dell'applicazione Web piuttosto che dover fornire il proprio.

Per fare questo, iniziare con quello che Oded cita nella sua risposta - creare un riferimento a System.Web.Security all'interno del codice .dll s' - poi all'interno di tale file che si può fare qualcosa di simile al seguente:

if (Membership.Provider != null) { 
    Membership.Provider.CreateUser(...); 
} else { 
    // Do something appropriate in a case where there is no Membership Provider 
} 

A questo point - se quanto sopra non funziona, è probabile perché l'applicazione Web non ha un fornitore appropriato configurato.

Una nota sul perché a farlo in questo modo ...

Il motivo si dovrebbe lasciare che l'applicazione Web di fornire la configurazione è di rispettare il principio di Separation of Concerns.MembershipProvider è una classe astratta che fornisce funzionalità predefinite, con un'implementazione molto limitata.

In altre parole, definisce che per gestire i membri, è necessario essere in grado di eseguire operazioni come CreateUser() e GetAllUsers(). Dice anche che dovresti essere in grado di configurare le impostazioni, come ad esempio la specifica di PasswordFormat e determinare se ciascun utente è RequiresUniqueEmail o meno.

Ciò che non fa è indicare dove memorizzare le informazioni dell'utente. Lo lascia fino all'implementatore (System.Web.Providers.DefaultMembershipProvider o YourNS.YourMembershipProvider).

L'applicazione che utilizza MembershipProvider determina quindi quali impostazioni fornire e quale implementazione utilizzare. In altre parole, è il lavoro di YourNS.YourMembershipProvider per specificare come gestire le informazioni, ma è probabile che l'Applicazione determini cosa utilizzare nell'archivio, ecc.

Quindi, seguendo lo schema sopra descritto, è possibile fornire tre livelli separati:

1. un'applicazione che consumano la MembershipProvider,
2. un assieme che prevede l'attuazione MembershipProvider e
3. un assemblaggio che utilizza qualsiasi MembershipProvider è configurato - e fa qualcosa con esso in nome della domanda (* questo è il livello che stai descrivendo nel tuo post, credo)

Si noti che se si segue questo modello - è ora possibile passare MembershipProviders in un secondo momento senza dover modificare nessuno degli altri livelli - perché questi livelli si basano sulla classe base di MembershipProvider - anziché fare affidamento sulla specifica implementazione. Questo può essere estremamente prezioso.