Powiązywanie dodatkowych informacji z członkostwem ASP.NET MVC

Question

Nie jestem pewien, czy powinienem zrobić to inaczej z MVC, ale jestem ciekawy, jakie jest zalecane podejście do dodawania dodatkowych informacji do konta użytkownika ASP.NET podczas korzystania z członkostwa dostawca? Również, jak powiązać to użycie z innymi podmiotami.

Zazwyczaj nie zawracam sobie głowy profilami i wolę dodawać dodatkowe informacje do tabeli, która po prostu odwołuje się do identyfikatora USERID. Czy jest to dobre/złe/akceptowalne dla podejścia ASP.NET MVC, czy może byłoby to alternatywa?

Answer 1

To dobre pytanie, z którym się zmagałem. Myślę, że istnieją trzy podstawowe podejścia;

1. Użyj dostawcy Profil - to sprawia, że ​​łatwo dodać właściwości ale kłopotliwe robić takie rzeczy jak generowanie tabeli użytkowników, szczególnie jeśli trzeba stosować filtry/wyszukiwania. API po prostu tego nie wycina.

2. Dodaj nową tabelę (lub rozszerz istniejącą tabelę), a następnie dołącz do tej. Będziesz wtedy musiał napisać własne metody, aby odzyskać niestandardowe dane.

3. Napisz własnego dostawcę członkostwa, który rozszerza klasę MembershipProvider.

Na moim ostatnim projekcie użyłem drugie podejście - Napisałem bardzo quck SQL, które realizowane tylko najpotrzebniejsze rzeczy potrzebne do tworzenia użytkowników, uwierzytelniania oraz zmianę haseł. Dla reszty wirtualnych metod właśnie rzuciłem NotImplementedException.

Dodałem następnie nową klasę, która dodała dodatkowe właściwości, których potrzebowałem i zrobiła to, aby można było utworzyć instancję, przechodząc w standardowym MembershipUser. Coś takiego:

public static CustomMember GetMember(MembershipUser user) 
{ 
    // Get your custom member 
} 

ten sposób można użyć standardowego MembershipUser dla większości rzeczy, ale jeśli chcesz uzyskać więcej informacji na temat bieżącego użytkownika robisz rzeczy tak:

MembershipUser user = Membership.GetUser(); 
CustomMember member = CustomMember.GetMember(user); 

ja być zainteresowanym, aby zobaczyć, jakie są podejścia innych ludzi.

Answer 2

Fakt, że korzystasz z MVC, nie powinien mieć znaczącego wpływu na sposób, w jaki traktujesz członkostwo i "dane użytkownika".

Zazwyczaj unikam również profili ASP.NET, a nawet domyślnego członkostwa w ASP.NET, preferując przeniesienie własnego dostawcy członkostwa i schematu "profilu" powiązanego z moją istniejącą tabelą użytkowników.

Zamieść komentarz, jeśli są Państwo zainteresowani dodatkowymi informacjami na temat dostawców członkostwa klienta.

Answer 3

Chciałbym zobaczyć dużo więcej opinii na ten temat i co ludzie robią. Obecnie korzystam ze standardowego systemu ASPNet/Member Provider w aplikacji mvc asp.net i nie podoba mi się to zbytnio.

Moje podejście polegało na zmianie tabeli aspnet_users i dodaniu całej gamy dodatkowych kolumn; CompanyId, StreetAddress itp.

Zapisałem ustawienia profilu użytkownika, w jaki sposób korzystają ze strony internetowej w profilu standardowym; z jakiego motywu korzystają, ile rekordów wyświetla lista stronicowanych i innych rzeczy.

Większość ludzi uważa, że ​​uzyskanie informacji w profilu i poza nim jest uciążliwe i z tego, co czytam w dużych systemach, może stać się wąskim gardłem wydajności związanym z serializacją.

Jestem skłonny do toczenia się na moich stołach, które lepiej pasują do mojego schematu aplikacji, implementacji niestandardowego dostawcy sql, a następnie sprawdzenia pisania dodatkowych atrybutów bezpieczeństwa w asp.net mvc, jeśli ich potrzebuję.