ASP.NET Benutzeranmeldung

Question

Ich habe eine einfache ASP.Net-Anwendung mit einer Datenbank aus Tabellen wie Klassen, Eltern, Schüler, Fächer und Lehrer erstellt.

Es gibt zwei Entitäten, die mit dieser Anwendung interagieren, indem sie sich anmelden und die Lehrer und Eltern werden.

Meine Frage ist, wie verknüpfe ich die Lehrer in meiner Teachers-Tabelle, anstatt jeden neuen Benutzer zu speichern, der sich in der AspNetUsers-Tabelle registriert, die mit AspNetIdentity geliefert wird.

Sobald ein Lehrer/Eltern sich anmeldet, möchte ich Details zu diesem Lehrer/Elternteil anzeigen können. Wenn sich zum Beispiel ein Lehrer anmeldet, möchte ich alle Klassen zeigen, die er/sie unterrichtet, die ich aus der Datenbank abrufe.

Ich bin neu in ASP.NET MVC, also ich appologies wenn ich etwas sehr offensichtliche frage. Jede Hilfe wird erteilt.

UPDATE

Ok so, nachdem der von Chris Vorschlag aus dem ApplicationUser erben konnte ich meine Datenbank aktualisieren, und ich habe jetzt die folgende Struktur für meine Datenbank.

Entity Data Model

Jetzt bin ich ein wenig verwirrt darüber, wo die Eltern und Lehrer Tabellen sind und wie genau werde ich diese Objekte aus der Datenbank abgerufen werden, wenn sie alle in einer Tabelle „AspNetUsers“.

UPDATE 2

So habe ich dieses Stück Code in meiner Account

public AccountController() 
      : this(new UserManager<ApplicationUser>(new UserStore<ApplicationUser>(new ApplicationDbContext()))) 
     { 
     } 

     public AccountController(UserManager<ApplicationUser> userManager) 
     { 
      UserManager = userManager; 
     } 

     public UserManager<ApplicationUser> UserManager { get; private set; } 

Und das ist, was die Register() -Methode wie folgt aussehen:

if (ModelState.IsValid) 
      { 
       var user = new ApplicationUser() { UserName = model.UserName, FirstName = model.FirstName, LastName = model.LastName }; 
       var result = await UserManager.CreateAsync(user, model.Password); 
       if (result.Succeeded) 
       { 
        var Teacher = new Teacher 
        { 
         UserName = model.UserName, 
         FirstName = model.FirstName, 
         LastName = model.LastName, 
        }; 

        // Add the Address properties: 
        user.UserName = model.UserName; 
        user.FirstName = model.FirstName; 
        user.LastName = model.LastName; 

        var roleStore = new RoleStore<IdentityRole>(new ApplicationDbContext()); 
        var roleManager = new RoleManager<IdentityRole>(roleStore); 
        await roleManager.CreateAsync(new IdentityRole("Teacher")); 

        await UserManager.AddToRoleAsync(user.Id, "Teacher"); 

        await SignInAsync(user, isPersistent: false); 
        return RedirectToAction("Index", "Home"); 
       } 

refering zu Chris Kommentar Wie richte ich eine Instanz von ApplicationUserManager ein, wenn sich ein neuer Benutzer als neuer Teacher registriert?

Answer 1

Da Sie AspNetIdentity verwenden, müssen Sie den Speichermechanismus ein wenig ändern, um AspNetIdentity wirklich zu nutzen. Eine einfache Sache ist, dass all diese Entitäten (Teacher/Parent), die eine Authentifizierung benötigen oder den Anmeldeprozess durchlaufen müssen, in der AspNetusers-Tabelle gespeichert werden sollten, um den Standardmechanismus des AspNetIdnetity-Authentifizierungsprozesses zu nutzen, der Ansprüche generiert. Wenn Sie die Benutzerdetails (die authentifiziert werden sollen) in Ihren benutzerdefinierten Tabellen und nicht in den Standardtabellen von AspNetIdentity speichern, verfügt sie über keinen Mechanismus, um dies nachzuverfolgen.

Es wird zwei Einheiten geben, die mit dieser Anwendung interagieren, indem angemeldet wird, was die Lehrer und Eltern sein wird.

Lehrer und Eltern werden viele gemeinsame Eigenschaften wie haben Vorname, Nachname, Handynummer usw., die in AspNetUsers Tabelle speichern durchaus Sinn macht und sie als Forderungen nach der Authentifizierung von AspNetIdentity zu erhalten.

Zum Beispiel, wenn ein Lehrer anmeldet Ich möchte alle Klassen zeigen er/sie lehrt, die ich aus der Datenbank

Für diese abruft Sie Fremdschlüssel aus AspNetUser ‚s haben müssen Tabelle

Answer 2

Einer der Gründe für die Existenz von Identity ist die Aktivierung der Erweiterbarkeit mit Authentifizierung. Ansonsten hätten wir alle einfach bei der alten ASP.NET-Mitgliedschaft bleiben können. Also, benutze es. Der beste Weg, dies zu bewältigen, ist die Vererbung. Ihre Basis „user“ wird ApplicationUser, und jede und alle Subtypen von „Benutzer“ aus, dass erben sollte:

public class Teacher : ApplicationUser 

public class Parent : ApplicationUser 

Dies wird zur Folge haben, die standardmäßig in Single-Table Vererbung, wo alle Eigenschaften von allen Subtypen von ApplicationUser werden alle in die gleiche Tabelle, dh , standardmäßig gehen. Ein Diskriminator Spalte wird hinzugefügt, was den Wert der Klasse Entity Framework enthalten instanziert soll, wenn der Datensatz aus der Datenbank abgefragt wird, das heißt Teacher, Parent oder ApplicationUser. In den meisten Fällen funktioniert das großartig. Der einzige zu beachtende Punkt ist, dass alle Eigenschaften von Subtypen in einer Tabelle enthalten sein müssen und daher für diese Typen keine Nullwerteigenschaften zulässig sind. wenn es irgendeine Eigenschaft auf Teacher waren, die Sie auf Datenbankebene erzwingen wollte immer einen Wert hatte, konnte man nicht tun zum Beispiel, dass, weil Parent oder ApplicationUser kein Mittel mit einem Wert haben würde. Sie können jedoch immer einen Wert auf der Ebene der Benutzeroberfläche anfordern, nur nicht auf der Datenbank.

Wenn das völlig inakzeptabel ist, können Sie Tabelle pro Typ Vererbung statt. Mit dieser Strategie würden Sie separate Tabellen für Parent und Teacher neben der AspNetUsers Tabelle erhalten. Für diese Tabellen gelten jedoch nur die für diesen Typ eindeutigen Eigenschaften. Alle Eigenschaften auf ApplicationUser würden bleiben in AspNetUsers und ein Eins-zu-Eins würde zwischen AspNetUsers und Teacher und Parent bzw. hinzugefügt werden. Dies bedeutet, dass Entity Framework zum Beispiel einen Join mit AspNetUsers haben muss, um eine Teacher abzurufen, und Joins sind immer weniger effizient, als nur eine Einzeltabelle abzufragen. Mit dieser Methode können Sie NOT NULL für Subtype-Eigenschaften auf Datenbankebene erzwingen. Dies ist also ein Kompromiss.

UPDATE

Identität Gerüste eine Implementierung von UserManager<TUser>, die nicht mehr generisch ist. Es gibt explizit TUser als ApplicationUser an, was bedeutet, dass jeder Untertyp, der darauf geworfen wird, auf diesen heruntergerechnet wird. Was ich spreche verändert sich gerade diese Klasse so es generic bleibt:

public class ApplicationUserManager<TUser> : UserManager<TUser> 
    where TUser : ApplicationUser 

Nun, ihr neues kann eine Instanz von ApplicationUserManager<Teacher> und es wird Teacher Fällen Abfrage nur Teacher Instanzen speichern, usw. Selbstverständlich, wenn Sie müssen in der Regel mit alle Benutzer arbeiten, müssen Sie eine Instanz von ApplicationUserManager<ApplicationUser> für diese neu.