1

Neu bei IdentityServer 4. Ich folgte dem IdentityServer4 EntityFramework-Beispiel in der Dokumentation.IdentityServer4 PersistedGrantDbContext & ConfigurationDbContext

Nach der Migration Skript

dotnet ef migrations add InitialIdentityServerPersistedGrantDbMigration -c PersistedGrantDbContext -o Data/Migrations/IdentityServer/PersistedGrantDb 
dotnet ef migrations add InitialIdentityServerConfigurationDbMigration -c ConfigurationDbContext -o Data/Migrations/IdentityServer/ConfigurationDb 

läuft Es funktioniert und jetzt meine Anwendung hat 3 DB Contexts.

  • ApplicationDbContext
  • PersistedGrantDbContext
  • ConfigurationDbContext

Meine Frage ist, was sind die beiden DB-Kontexte für? Was ist der Unterschied zwischen dem Anwendungs-DB-Kontext und den anderen beiden?

Wenn ich irgendwelche Modelle aktualisiere oder hinzufüge, muss ich alle drei aktualisieren? Oder wann sollte ich eine Migration für den ApplicationDbContext ausführen und wann für die anderen beiden ausführen.

Jeder Einblick oder Literatur zu diesen wird geschätzt. Danke.

+0

Die Idee besteht darin, die Entitäten aufzuteilen, so dass Sie nur die benötigten Tabellen konsumieren und die App also nicht alles gleichzeitig laden muss, um Leistung zu erzielen und den Zugriff zu beschränken. https://stackoverflow.com/questions/11197754/entity-framework-one-database-multiple-dbcontexts-is-this-a-bad-idea – Jasen

+0

@Jasen macht Sinn, danke. Gibt es einen Einblick darüber, wie der PersistedGrantDbContext und der PersistedGrantDbContext in IdentityServer4 verwendet werden? –

+0

Ich bin nicht vertraut mit den Details von IdentityServer. Ich denke, sie behalten die Grants in einem separaten Geschäft von der Serverkonfiguration aus Ihrem Anwendungsspeicher. – Jasen

Antwort

3

Ich habe es herausgefunden. Ich lasse das für jeden, der darüber verwirrt ist, wie ich war.

Es gibt 3 DB Kontexte und, wie @Jasen erwähnt, ist es, den Zugriff auf die Entitäten oder Tabellen zu teilen.

IdeneityServer4 + EntityFramework + ASP.NET Identität erstellt die folgenden Tabellen in der Datenbank:

SQL Server Tables

Die Kontexte verwendet, sind die folgenden zu verweisen:

ApplicationDbContext - verantwortlich für Anwender mit ASP beteiligt .NET-Identitäts-Tabellen

  • dbo.AspNetRoleClaims
  • dbo.AspNetRoles
  • dbo.AspNetUserClaims
  • dbo.AspNetUserLogins
  • dbo.AspNetUserRoles
  • dbo.AspNetUsers
  • dbo.AspNetUserTokens

PersistedGrantDbContext - verantwortlich für die Speicherung von Zustimmung, Autorisierungscodes , Aktualisierungstoken und Referenztoken

  • dbo.PersistedGrants

ConfigurationDbContext - verantwortlich für alles andere in der Datenbank verbleibenden

So in Bezug auf Migration, wenn ich eines der Modelle ASPnet Identität aktualisieren (d ApplicationUser) dann würde ich die Migration auf dem ApplicationDbContext ausführen.Alle Clienttabellen oder andere Bereiche werden im ConfigurationDbContext ausgeführt. Und um auf die Entitäten (oder Tabellen) zuzugreifen, wäre der entsprechende Kontext.

Verwandte Themen