2009-09-28 4 views

Antwort

10

Es ist die Trennung von Identitäts-/Authentifizierungsverwaltung von der Mitgliederverwaltung. Die "große" Benutzertabelle ist das eigentliche Identitäts-Repository - wenn Sie beispielsweise SQL verwenden möchten, um Ihre Identitätsdaten zu speichern, geht alles hier hinein. Möglicherweise möchten Sie jedoch eine andere Quelle, z. B. Active Directory, als Identitäts-Repository verwenden. Sie validieren stattdessen die Identität und die Authentifizierung, müssen aber dennoch eine Möglichkeit haben, den SQL-basierten Rollen/Zugehörigkeitsdaten zu den AD-basierten Identitätsdaten beizutreten. Hier kommt der kleinere Tisch rein - gerade genug Informationen, um diese Beziehungen aufrechtzuerhalten.

+0

Ich verlasse Asp.net-Mitgliedschaft, weil viele Tische ich nicht brauche, und seit ich einige Sachen gemacht habe, habe ich die eingebaute Methode nutzlos gemacht. Also versuche ich herauszufinden, ob ich die Daten so aufteilen oder in einen Tisch stecken soll. Was ist der empfohlene Ansatz? – chobo2

+1

@ Chobo2 schwer zu sagen, ohne Ihre Bedürfnisse zu kennen. Ich würde jedoch sagen, dass, wenn der ASP.NET-Anbieter alles tut, was Sie brauchen und vieles, was Sie nicht brauchen - Sie wollen vielleicht dabei bleiben. Bauen Sie Ihre eigenen sind Kosten, die Sie für bessere Dinge ausgeben könnten. Wenn es jedoch bestimmte Funktionen gibt, die Sie benötigen, entwerfen Sie zuerst Ihren Anbieter. –

2

Es dient zum Sichern mehrerer Anwendungen aus einer einzigen Benutzerdatenbank; aspnet_membership hat UserId und ApplicationId, so dass jeder Benutzer ein anderes Passwort für mehrere Anwendungen haben kann (und auch aus einer Anwendung ausgeschlossen werden kann, aber nicht aus einer anderen).

+2

Das stimmt, aber die andere Tabelle hat diese Information ebenfalls, also haben Sie nicht geantwortet, warum die zwei verschiedenen Tabellen existieren. –

Verwandte Themen