Pomóż mi zdecydować, czy używać domyślnych dostawców ASP/NET/ról, czy pisać niestandardowych dostawców.

Question

Spędziłem dużą część wczorajszego czytania na ten temat i wciąż mam wrażenie, że nie jestem pewien, w którą stronę pójść. Pochodzę z tła "roll your own", jeśli chodzi o uwierzytelnianie i autoryzację. Nigdy nie używaliśmy uwierzytelniania Forms, nie mówiąc już o interfejsie API Membership. Patrząc na nasz stary kod, używalibyśmy zmiennych sesji do przechwytywania/kontrolowania, czy użytkownik jest zalogowany itp. Z tym nowym projektem, który zamierzam podjąć, chcę przywrócić nas na właściwe tory z tym, co powinniśmy byli zrobić na początku, użyj narzędzi dostarczonych przez framework.

Mam już schemat bazy danych, z którym będę pracował, ale nie jest on osadzony w kamieniu; W razie potrzeby mogę wprowadzić w nim zmiany. W tym schemacie istnieje już tabela Użytkownicy, wykorzystująca liczbę całkowitą jako klucz podstawowy. Ta tabela zawiera również inne informacje, takie jak imię i nazwisko. Posiadam również klucze obce oparte na UserId na inne tabele, takie jak telefon i adres. Poniżej przedstawiam niektóre z zalet/wad, które przychodzą na myśl.

domyślnego dostawcy

Plusy

• mniej kodu.
• Możliwość korzystania ze wszystkich powiązanych elementów sterujących serwera, takich jak Login, ChangePassword.

Wady

• Niektóre kontrole nie mogą być usedful do mnie po wyjęciu z pudełka. Na przykład CreateUserWizard, będę musiał ewentualnie przechwytywać inne informacje podczas tworzenia użytkownika, takie jak informacje o telefonie i adresie do powiązanych tabel. Nie jestem pewien, czy to czyni tę kontrolę bezużyteczną dla mnie.
• Będę musiał utworzyć klucze obce w powiązanych tabelach (telefon, adres) do identyfikatora użytkownika, który jest identyfikatorem GUID w domyślnym dostawcy.
• Jeśli utworzę te ograniczenia klucza obcego, a nie wykorzystam usuwania kaskadowego; Będę musiał również usunąć powiązane wiersze w tabelach kluczy obcych. Potencjalnie trzeba użyć czegoś w rodzaju obiektu TransactionScope, aby upewnić się, że wszystko to jest operacją atomową.

klienta dostawcze

Plusy

• możliwość wykorzystania istniejących tabel schematu.
• Łatwiejsze wyodrębnianie uwierzytelniania/autoryzacji do usługi w linii.

Wady

• muszą zapewnić realizację większości/wszystkiego sam.
• Aby użyć dowolnej kontrolki, będę musiał podać ich wymaganą implementację w dostawcy.

Być może są jeszcze inne rzeczy, których jeszcze nie brałem pod uwagę, ponieważ nigdy wcześniej ich nie używałem, co sprawia, że ​​czuję się trochę nieswojo.

Dziękuję.

Answer 1

Niedawno musiałem dokonać tego samego wyboru i zdecydowałem się na stworzenie niestandardowego dostawcy.

Mój największy powód, aby to zrobić sprowadza się do domyślnego schematu db. Wszystkie domyślne obiekty db są tworzone w schemacie dbo i są poprzedzone prefiksem 'aspnet_' lub 'vw_aspnet', itd. Dla mnie było to prawdziwe wyłączenie. Jeśli jeszcze ich nie widziałeś, uruchom program aspnet_regsql.exe, aby je utworzyć.

Ponadto, Steven Sanderson mówi to w Pro ASP.NET MVC 2 Framework:

... SqlProfileProvider używa szczególnie obrzydliwe schematu bazy danych, w której przechowywane są wpisy profilu jako oddzieloną dwukropkami nazwa/wartość pary, więc zasadniczo nie da się zapytać.

Ogólnie rzecz biorąc, warto śledzić interfejs API ze względu na wyraźne oddzielenie problemów, ponowne wykorzystanie w różnych projektach i integrację z resztą środowiska ASP.NET, ale będziesz chciał używać tylko wbudowanych dostawców pamięci masowej SQL dla małych firm. lub projekty jednorazowe.

Nie przeszedłem jeszcze całego procesu tworzenia niestandardowych dostawców (wykonałem częściową implementację podczas odtwarzania z magazynu Azure Table), ale zamierzam korzystać z tych dostawców w wielu projektach w przyszłości, więc uważam, że wysiłek będzie tego wart.

Answer 2

Osobiście przejdę do tego, co zapewnia framework. W tym przypadku nie ma powodu, aby uruchamiać własne uwierzytelnianie.

W przeszłości mogłeś chcieć robić rzeczy samemu, ale obecnie nie ma ku temu powodu.

Myślę, że gdybyś spróbował napisać to samodzielnie, ponownie tworzyłbyś koło, a jego wykorzystanie zajęłoby zbyt dużo czasu i zasobów, by to naprawić. Zwłaszcza, gdy mamy do czynienia z bezpieczeństwem.

Answer 3

Jeśli tworzysz nową aplikację, nie zawaham się użyć domyślnego dostawcy asp.net. zawsze możesz zdecydować, że nie będziesz używać domyślnych elementów sterujących i programowo tworzyć własne. można również zaoszczędzić wiele czasu, korzystając z dowolnego narzędzia do zarządzania użytkownikami stworzonego przez opensource. Jednocześnie zawsze można rozszerzyć informacje zawarte w tabelach domyślnych.

Answer 4

Osobiście używam SqlMembershipProvider jako samodzielnej jednostki, podczas gdy reszta mojej bazy danych jest w Oracle. Nigdy nie patrzę na bazę danych, więc nazwy i identyfikatory GUID nie przeszkadzają mi (poza zasięgiem wzroku, w umyśle). Po prostu działa po wyjęciu z pudełka, co jest świetne!

W moim scenariuszu, mam tabelę użytkowników w bazie danych Oracle, które wstawiam/usuwam, gdy członkowie członkostwa są tworzeni/usuwani (brak identyfikatorów GUID). Uważam, że baza danych członkostwa jest rekordem "głównym", a tabela Oracle jest tam zasadniczo dla referencyjnej integralności tabel pomocniczych. To nie jest tak naprawdę zrobione w oficjalnej transakcji, ale używam try/catch, aby zachować synchronizację na tyle dobrze.

Dostawca roli jest naprawdę ograniczony i jeśli chcesz mieć jakąś hierarchiczną lub dynamiczną rolę, jesteś wznoszący toast. Ale to oddzielny system całkowicie odizolowany od członkostwa i nie musisz go używać.

Sterowanie nie jest złe. Wiele z nich obsługuje szablony, dzięki czemu można dodawać do nich własne elementy sterujące i mieć wiele zdarzeń, które można w nich wciągnąć. Nie bój się rzucić własnych kontrolek, ale najpierw daj szansę domyślnym kontrolom. Łatwość użycia interfejsu API ułatwia naprawdę tworzenie tych elementów sterujących.