Ich muss an dieser Stelle mal meine Zufriedenheit über die neuen Login-Controls von ASP.NET 2.0 loswerden.
Ich habe die letzten Tage intensiv damit verbracht, selbige zu nutzen, um einen geschützten Userbereich in einen Shop zu implementieren. Normalerweise hätte ich so etwas wie die letzten Jahre auch einfach mit Sessions selbst gestrickt - das hat sich bewährt, die Vorgehensweisen sind klar - der Aufwand aber auch enorm (da Neuentwicklung).
Von letzterem abgeschreckt habe ich mir dann mal die Login-Controls und das ganze Membershipmanagement von ASP.NET 2.0 angeschaut, frei nach dem Motto "schlimmer kanns ja nicht werden" - was den Aufwand anbelangt.
Der Anfang war schnell gemacht: System-Objekte in der Datenbank erzeugt, und die Controls für Benutzerregistrierung, Login usw. per Drag & Drop in meiner Anwendung platziert. Wie nicht anders erwartet und so ja in Ansätzen auch bereits beim Community Boot Camp im Sommer gesehen, funktionierte alles anstandslos.
Es ist schon sehr praktisch, wenn man sich um obligatorische Funktionalitäten wie Passwort-Wiederherstellung, Passwort-Änderung, Benutzer-Login, Loginstatus-Darstellung usw. einfach drücken kann. Dazu kommt noch, dass alle Controls sehr vorbildlich sind, was ihre individuellen Anpassungsmöglichkeiten betrifft. Man kann fast jedes Control zerlegen und wirklich seinen eigenen Vorstellungen entsprechend anpassen.
Positiv überrascht hat mich in dieser Reihe übrigens das LoginView-Control:
"LoginView1" runat="server">
Hallo Gast!
Hallo "LoginName1" runat="server" />!
Kein lästiges
if(Session["Login"] != null) { panelLoggedIn.Visible = true }
mehr. Ist das nicht cool? :-)
Einiges Kopfzerbrechen bereitete mir aber indes die eigentliche Kernaufgabe: die Anbindung dieses Membership-Layers an die bereits vorhandene Infrastruktur - genauer, die Benutzertabelle(n), die in diesem Fall der Kundentabelle entspricht.
Es hat mich einige Tage an Recherche und vielen Selbstzweifeln gekostet, das Thema ist ja leider noch ziemlich dünn dokumentiert. Ich konnte mir nicht recht vorstellen, was denn nun der beste Weg wäre, die Daten zu speichern. System-Tabellen erweitern? Dieses komische Profil-System nutzen, bei dem sämtliche Properties pro Profil in ein nvarchar-Feld geklatscht werden? Die Erleuchtung brachte mir dann schließlich eines der Samples, die ClubWebsite (funktioniert übrigens auch mit SQL Server 2000 1a!):
Man behält einfach die bestehende Kundentabelle um in ihr das Nutzerprofil zu speichern, und erweitert das CreateUserWizard-Control um entsprechende Steps und Felder, welche man dann von Hand in die Datenbank speichert (siehe ClubWebsite, member_register.aspx). Funktioniert wunderbar und ist flexibel erweiterbar. Vor allem aber ist man unabhängig von den Launen Microsofts - d.h. wenn die mal was an der Struktur der Profil-Tabellen usw. ändern, bekommt man Probleme (danke Hannes für den Denkanstoß).
Fazit: es hat mich viel Zeit und Nerven gekostet, hat am Anfang und am Ende aber eine Menge Spaß gemacht - und ich werde nie wieder irgendwas mit Sessions selbst zusammenstricken, zumindest nicht wenn ich mit .NET 2.0 arbeiten kann.
