Membership.CreateUser() w bibliotece klas

Question

Jestem w trakcie przenoszenia kodu z biblioteki App_Code do biblioteki klas.

Tworzę użytkowników programowo przy użyciu Membership.CreateUser.

Jak mogę to zrobić w bibliotece zajęć, w której nie ma dostępu do dostawcy członkostwa skonfigurowanego w web.config?

Answer 1

Dodaj dyrektywę using do przestrzeni nazw System.Web.Security w swojej klasie - da to bezpośredni dostęp do klasy Membership.

C#:

using System.Web.Security; 

VB.NET:

Imports System.Web.Security 

Answer 2

Można do niego dostęp w dowolnym miejscu poniewaz klasy Membership jest statyczną reprezentację aktualnego dostawcy setted przez system dostawcy ASP.NET.

Answer 3

Rozwiązałem problem przez skopiowanie całego pliku web.config na mój app.config. Używałem aplikacji konsolowej. Myślałem, że skopiowałem niezbędne sekcje, ale dopóki nie skopiowałem wszystkiego, dane nie trafiły do ​​bazy danych

Answer 4

Zanim pokażę Ci, jak działa część kodu - musisz zrozumieć, jak ustawienia są ładowane w tego rodzaju scenariuszu .

Kiedy masz aplikacją internetową, która ma zamiar załadować plik .dll - i to plik .dll ma dostęp do MembershipProvider który ustawił aplikacja - trzeba zrobić kilka założeń.

1. aplikacja internetowa ma MembershipProvider
2. Aplikacja internetowa zapewnia ustawienia dla tego MembershipProvider w Web.Config
3. Aplikacja internetowa ładuje .dll poprawnie

Ponieważ plik .dll powinny być zawarte w w katalogu aplikacji WWW /bin powinieneś móc polegać na konfiguracji Aplikacji WWW zamiast dostarczać własne.

Aby to zrobić, należy rozpocząć co Oded wspomina w swojej odpowiedzi - utworzyć odwołanie do System.Web.Security w swoim .dll „s Code - wtedy w tym pliku można zrobić coś jak następuje:

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

W ten point - jeśli powyższe nie działa, jest to prawdopodobnie spowodowane tym, że Twoja aplikacja internetowa nie ma skonfigurowanego odpowiedniego dostawcy.

Uwaga na dlaczego zrobić to w ten sposób ...

Powodem należy pozwolić Web Application zapewnić konfiguracja jest zgodna z zasadą Separation of Concerns.MembershipProvider to klasa abstrakcyjna, która zapewnia domyślną funkcjonalność - z bardzo małą implementacją.

Innymi słowy - określa, że ​​aby zarządzać członkami, musisz mieć możliwość wykonywania operacji, takich jak CreateUser() i GetAllUsers(). Mówi ona również, że powinieneś być w stanie skonfigurować ustawienia, takie jak określanie PasswordFormat i ustalanie, czy każdy użytkownik ma być użytkownikiem, czy nie, RequiresUniqueEmail.

To, czego nie robi, to informacja, gdzie przechowywać informacje o użytkowniku. Pozostawia to wykonawcę (System.Web.Providers.DefaultMembershipProvider lub YourNS.YourMembershipProvider).

Aplikacja, która korzysta z MembershipProvider, określa następnie ustawienia, które należy wprowadzić, oraz rodzaj implementacji. Innymi słowy - to zadanie YourNS.YourMembershipProvider, aby określić w jaki sposób informacje są zarządzane, ale jest prawdopodobne, Application, który powinien określić, jakie ConnectionString wykorzystywać w swojej pamięci, itp

Tak - według wzoru I opisanej powyżej pozwala na wprowadzenie trzech oddzielnych warstw:

1. aplikacji, które zużywają MembershipProvider,
2. zespół, który zapewnia realizację MembershipProvider i
3. zespół, który wykorzystuje dowolnie MembershipProvider jest skonfigurowany - i robi coś z nim w imieniu aplikacji (* to jest warstwa opisujesz w swoim poście, wierzę)

Zauważ, że jeśli się tego wzorca - można teraz przełączać MembershipProviders w późniejszym czasie bez konieczności zmiany żadnej z pozostałych warstw - ponieważ te warstwy opierają się na klasie bazowej MembershipProvider - zamiast polegać na Twojej konkretnej implementacji. To może być niezwykle cenne.