Owin Kontext auf Asp. Net Identität

Question

Ich habe verwirrt, wie dieser Code von ASP. NET Identität Vorlage implementiert wird.

private ApplicationSignInManager _signInManager; 
private ApplicationUserManager _userManager; 
private ApplicationRoleManager _roleManager; 

public AuthController() { } 

public AuthController(ApplicationUserManager userManager, ApplicationSignInManager signInManager, ApplicationRoleManager roleManager) 
{ 
    UserManager = userManager; 
    SignInManager = signInManager; 
    RoleManager = roleManager; 
} 

public ApplicationRoleManager RoleManager 
{ 
    get { return _roleManager ?? HttpContext.GetOwinContext().Get<ApplicationRoleManager>(); } 
    private set { _roleManager = value; } 
} 

public ApplicationSignInManager SignInManager 
{ 
    get { return _signInManager ?? HttpContext.GetOwinContext().Get<ApplicationSignInManager>(); } 
    private set { _signInManager = value; } 
} 

public ApplicationUserManager UserManager 
{ 
    get { return _userManager ?? HttpContext.GetOwinContext().GetUserManager<ApplicationUserManager>(); } 
    private set { _userManager = value; } 
} 

Warum haben wir den AuthController mit Parameter? Dependency Injektionszweck? Und wenn keine Einspritzung geschieht, dann rief der owincontext, der auf Startup.cs spezifiziert wird? Können wir den owincontext ignorieren und nur die Injektion verwenden?

Und wenn ich versuchte zu debuggen, wie das läuft, ist es nur durch den parameterlosen Konstruktor und es bricht meinen Code. Wird dieser parametrisierte Konstruktor nicht verwendet?

Irgendeine Idee? Vielen Dank.

Answer 1

In der Tat ist diese Vorlage für die Arbeit mit DI-Container und ohne eine - um alle Fälle abzudecken. Wie Sie gesagt haben - wenn DI verwendet wird, wird Konstruktor mit Parametern verwendet.

Und wenn nichts in Konstruktor zur Verfügung gestellt wurde, dann greifen Sie in OWIN und erhalten Instanzen von erforderlichen Objekten.

Ja, wenn Sie eine DI verwenden, können Sie Eigenschaften mit HttpContext.GetOwinContext() entfernen und nur Konstruktor mit Parametern verlassen.

Wenn Sie DI verwenden, aber der Controller über den parameterlosen Konstruktor erstellt wird, dann haben Sie DependencyResolver nicht für Asp.Net konfiguriert. In Global.asax.cs (oder wo immer Sie die DI-Konfiguration ausführen) müssen Sie DependencyResolver.SetResolver(myContainerWrapper); aufrufen, wobei myContainerWrapperIDependencyResolver ist und Sie nachsehen müssen, wie Ihr DI-Container in Asp.Net integriert ist.