Wie die Feinabstimmung ein Membership Provider?

Question

Nachdem alle Antworten auf meine letzte Frage zu Feinabstimmung erwies sich als nützlicher zu sein, als ich erwartet hatte, dachte ich, dass ich auch eine ähnliche Frage über den MembershipProviders fragen würde.

Okay, erstens zu klären: Ich weiß, was für eine Mitgliedschaft, Rolle und Profil-Provider ist, wie mein eigenen zu implementieren, und wie sie konfigurieren, und die meisten der Dinge über sie
. Die Implementierung einer Rolle und Profil-Provider ist ziemlich einfach, weil sie nur einfache CRUD die meiste Zeit benötigen. (Eine einzelne Zeile von LINQ reicht für etwa die Hälfte der Roleprovider Methoden.)

Allerdings ist die Mitgliedschaft Provider ist ein differend Tier. Viele von Ihnen können erkennen, dass es die SR (Single Responsibility) Prinzip verstößt, weil sie alles, um die Benutzerverwaltung im Zusammenhang zu tun hat. Während dies eine Menge Raum für Anpassungen verlässt, hat es seine Nachteile auch. Es gibt keine Informationen über das Internet über das, was ihre EXACT erwartetes Verhalten ist, wie wenn sie sollen Ausnahmen werfen oder einfach null zurück, und solche Sachen.

Ich verwende diese Beispielimplementierung als Referenz, sondern auch mehrere Widersprüche enthält.

• Zum Beispiel verwendet er seine eigenen ValidateUser Verfahren zur Verwendung in den Change Verfahren zur Anmeldeinformationen zu überprüfen. Aber die ValidateUser aktualisiert auch die LastLoginDate des Benutzers auf das aktuelle Datum. So erwartet der Rahmen, dass ich es in meinem eigenen Provider festgelegt als auch, oder ist es einfach ein Fehler in der Probe?
• Die andere ist: das Change Methode eine Ausnahme wirft jedes Mal, wenn das neue Passwort Validierung, aber AngelegtVon nicht immer eine Ausnahme werfen, es gibt einfach false
.

• Und last, but not least: Es zählt die ungültige Anmeldeversuche des Benutzers und sperrt sie, wenn sie einen Schwellenwert überschreitet. Dies ist zwar gut, aber es erfordert eine manuelle Aktion, um die Benutzer zu entsperren. Ist es ein Problem, wenn mein Provider den Benutzer automatisch nach einer gewissen Zeit entsperrt?

• (EDIT) Habe ich fast vergessen: die AngelegtVon Methode in der Probe fügt die ID aus dem Methodenparameter. Ich glaube tatsächlich, diese schlechte Praxis, weil ich inters mit Auto incement als IDs verwenden, so dass sie von einem Methodenparameter Einfügen ist keine Option. Soll ich den Parameter einfach ignorieren, oder verlangen, dass sein Wert null ist und eine Ausnahme auslösen, wenn es nicht?

Alles in allem hat ASP.NET keine Annahmen über das Verhalten eines MembershipProvider?
Gibt es eine Dokumentation, die beschreibt, wann sollte ich eine Ausnahme oder nur return null werfen?

Ich habe versucht, auch eine Reihe von generischen Unit-Tests zu finden, das einige Hinweise über das erwartete Verhalten liefern würde, aber kein Glück, fand ich viele Artikel über „Unit-Tests sind gut“ und „Wie Unit-Test eines MembershipProvider“ , aber nicht ein, wo es würde keine eigentlichen Tests sein.

Vielen Dank im Voraus für alle!

Answer 1

Sie können für die Führung MSDN konsultieren. Zum Beispiel RoleProvider.RemoveUsersFromRoles stellt die folgende Anleitung:

RemoveUsersFromRoles heißt durch RemoveUserFromRole, RemoveUsersFromRole, RemoveUserFromRoles und RemoveUsersFromRoles Methoden der Rollen-Klasse des angegebenen entfernen Benutzer aus den angegebenen Rollen bei der Datenquelle. Nur Rollen für die Konfiguriert Application sind geändert.

Wenn eine der angegebenen Rollennamen sind nicht für die konfigurierte gefunden application, empfehlen wir, Ihr Provider throw a Provider.

Wenn eine der angegebenen Benutzernamen sind nicht mit einem der zugehörigen angegebene Rollennamen für die Konfiguriert application wir empfehlen, dass Ihr Provider ein Wurf Provider.

Wenn eine der angegebenen Benutzernamen ist null oder eine leere Zeichenfolge, wir empfehlen, dass Ihr Provider werfen ein Ausnahme.

Wenn eine der angegebenen Rollennamen ist null oder eine leere Zeichenfolge, wir empfehlen, dass Ihr Provider werfen ein Ausnahme.

Wenn Ihre Datenquelle unterstützt Transaktionen, empfehlen wir Ihnen, umfassen, die jeweils in einer Entfernungsoperation Transaktion und dass Sie rollen wieder die Transaktion und wirft eine Ausnahme, wenn jeder entfernen Vorgang fehlschlägt.

Und RoleProvider.GetRolesForUser sagt:

GetRolesForUser wird durch die GetRolesForUser Methode der Rollen-Klasse aufgerufen, um die Rollennamen abzurufen, dass der angegebene Benutzer mit der Datenquelle verknüpft ist. Nur die Rollen für die konfigurierte Application abgerufen werden.

Wenn keine Rollen für den angegebenen Benutzer existieren für den konfigurierte Anwendungsnamen, empfehlen wir, dass Ihr Provider ein String-Array zurückgeben ohne Elemente.

Wenn der angegebene Benutzername ist null oder eine leere Zeichenfolge ist, empfehlen wir, dass Ihr Provider eine Ausnahme aus.

Aber in der Praxis gibt es nur wenige Methoden und Verhaltensweisen in jedem Provider, die erforderlich sind und zu erwarten. Der Rest sind Unterstützung für die Funktionen, die Sie implementieren möchten.

Nach mehreren Jahren mit dem Standard-Provider-Stack zu tun Ich habe kommen einige der Dinge zu verstehen, die Sie geben Pause in Bezug auf den Proben Sie verknüpfen, das eine sehr einfache Implementierung ist, dass Schnitte Ecken, zum Beispiel in den Change Verfahren.

Wenn Sie Reflektor verwenden und untersuchen SqlMembershipProvider werden Sie einige markante Unterschiede bemerken ...

Zum Beispiel:

• ValidateUser Updates Login Datum weil, na ja, wird der Benutzer sich anmelden und es tut dies, indem .CheckPassword mit wahrem für UpdateLastLoginTime Aufruf. Passwort ändern ruft die gleiche Methode liefert aber falsch.

• Die AngelegtVon Methode akzeptiert einen ProviderUserKey weil die SPROC wird auch eine Benutzer-ID-Parameter übernehmen. Dies ist, damit die Erholung und syncronization zwischen der Mitgliedschaft und Benutzer-Tabellen. Als Verbraucher des API würden Sie normalerweise nicht diese Funktionalität nutzen, aber der Provider-Stack funktioniert intern.

• In Bezug auf Aussperrung .. Es ist an Ihnen. Das ist, was benutzerdefinierten Anbieter Umsetzung geht: immer das gewünschte Verhalten. Wie gesagt, es gibt nur sehr wenige systematische Anforderungen.

Also, das bringt uns zum letzten Teil Ihrer Frage (beide Ziffern auf die gleiche Sorge anspielen): erwartetes Verhalten und Unit-Tests ...

Da das Verhalten eines Anbieters weitgehend willkürlich ist und es gibt nur wenige erwarteten Verhaltensweisen, eine etablierte Reihe generischer Tests würden nur sehr wenige Methoden enthalten. Sie müssen Schreibtests, die sich auf das Verhalten anwendenIhre Implementierung.

Als abschließende Bemerkung, ich schlage vor, Sie finden und < a href = "http://download.microsoft.com/download/a/b/3/ab3c284b-dc9a-473d-b7e3-33bacfcc8e98/ProviderToolkitSamples.msi" rel = "nofollow noreferrer"> Download der Asp .NET-Provider-Toolkit Proben. Es bietet Sie mit Quellcode für den vollständigen SQL-Provider-Stack arbeitet und gibt Ihnen einen Einblick darüber, wie ‚echter‘ Provider implementiert.

Nachgedanken :

In diesem Moment, ich bin die Umsetzung einen vollständigen SQLite-Provider-Stack, der zu 100% kompatibel mit dem Standard-SQL-Stapel ist. Die Testsuite überprüft Verhalten Parität zwischen meinem Stack und asp.net ist. Wenn Sie meinen Blog Hit über mein Profil und Kontakt ich werde ich Dich wissen lassen, wenn die Tests abgeschlossen sind und Sie können sie als Maßstab verwenden, was genau aus dem Standard-Stack erwartet wird.