c# - 使用简单注入(inject)器注册 IAuthenticationManager

Question

我正在为 Simple Injector 进行配置设置，我已将所有注册移动到 OWIN 管道。

现在的问题是我有一个 Controller AccountController它实际上将参数作为

public AccountController(
    AngularAppUserManager userManager, 
    AngularAppSignInManager signinManager, 
    IAuthenticationManager authenticationManager)
{
    this._userManager = userManager;
    this._signInManager = signinManager;
    this._authenticationManager = authenticationManager;
}

现在我的 Owin Pipeline 配置看起来像这样

public void Configure(IAppBuilder app)
{
    _container = new Container();
    ConfigureOwinSecurity(app);
    ConfigureWebApi(app);
    ConfigureSimpleinjector(_container);

    app.Use(async (context, next) =>
    {
        _container.Register<IOwinContext>(() => context);
        await next();
    });

    _container.Register<IAuthenticationManager>(
        () => _container.GetInstance<IOwinContext>().Authentication);

    _container.Register<SignInManager<Users, Guid>, AngularAppSignInManager>();
}

private static void ConfigureOwinSecurity(IAppBuilder app)
{
    app.UseCookieAuthentication(new CookieAuthenticationOptions
    {
        AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
        CookieName = "AppNgCookie",
        //LoginPath = new PathString("/Account/Login")
    });
}

private static void ConfigureWebApi(IAppBuilder app)
{
    HttpConfiguration config = new HttpConfiguration();
    WebApiConfig.Register(config);
    app.UseWebApi(config);
}

private static void ConfigureSimpleinjector(Container container)
{
    SimpleInjectorInitializer.Initialize(container);
}

Simple Injector Initializer 看起来像这样

private static void InitializeContainer(Container container)
{
    container.Register<DbContext, AngularAppContext>();

    container.Register<IUserStore<Users, Guid>, AngularAppUserStore>();
    container.Register<IRoleStore<Roles, Guid>, AngularAppRoleStore>();

    container.Register<UserManager<Users, Guid>, AngularAppUserManager>();
    container.Register<RoleManager<Roles, Guid>, AngularAppRoleManager>();
    //container.RegisterPerWebRequest<SignInManager<Users, Guid>, AngularAppSignInManager>();

    container.Register<IdentityFactoryOptions<AngularAppUserManager>, IdentityFactoryOptions<AngularAppUserManager>>();
    //container.Register<IAuthenticationManager>(() => HttpContext.Current.GetOwinContext().Authentication);

    //container.Register<SignInManager<Users, Guid>, AngularAppSignInManager>();
    // For instance:
    // container.Register<IUserRepository, SqlUserRepository>();
}

现在的问题是 Controller 无法注册 IAuthenticationManager .我尝试使用

container.Register<IAuthenticationManager>(
    () => HttpContext.Current.GetOwinContext().Authentication);

但这让我有异常(exception):

System.InvalidOperationException: No owin.Environment item was found in the context.

在这一行

container.Register<IAuthenticationManager>(
    () => HttpContext.Current.GetOwinContext().Authentication);

我也尝试过而不是使用 HttpContext.Current.GetOwinContext().Authentication使用上面提到的配置 public void Configure(app)注册方法 app.Use() .然后通过容器解析它以获取 IAuthenticationManager .但每一种可能性都让我失败了。

我在这里缺少什么？为什么 HttpContext.Current.GetOwinContext().Authentcation无法从 OwinContext 解析身份验证？

如果不是，为什么通过 app.Use 进行相同的配置也不工作？

Answer 1

正如 TrailMax 已经提到的，您可能在调用 container.Verify() 期间引发了异常。 .在应用程序启动时没有 HttpContext ，因此异常(exception)。

虽然撤掉了对container.Verify()的电话将“解决”问题，我建议不要这样做，我会在下面建议一个更好的解决方案。

NightOwl888 引用了 Mark Seemann 的一篇旧文章(我非常尊重他在 DI 方面的工作)。在 that article Mark 解释了为什么他认为验证容器没有用。然而，这篇文章似乎已经过时，并且与 Mark 较新的文章有冲突。在 a newer article马克解释说使用 Pure DI 的一大优势(即不使用 DI 容器的依赖注入(inject))是 it provides the fastest feedback about correctness that you can get . Mark 和我们其他人显然很重视编译器的反馈和来自静态代码分析工具的反馈，作为快速反馈机制。两者都简单的注入(inject)器.Verify()和 Diagnostic Services尝试将这种快速反馈带回来。在我看来，Simple Injector 的 .Verify()方法承担编译器在执行纯 DI 时会为您完成的工作，而诊断服务在某种意义上是专门用于您的 DI 配置的静态代码分析工具。

虽然容器确实不可能对其配置进行 100% 验证，但验证对我来说仍然是一种有值(value)的做法。认为对 .Verify() 的简单调用是愚蠢的。将导致完全没有错误甚至是工作应用程序。如果有人可能认为这就是“验证”您的 DI 配置的含义，我理解他们为什么会争辩说此功能毫无值(value)。听起来像是一句老生常谈。那里没有容器，包括 Simple Injector，它假装具有这样的功能。

您当然仍然负责为例如编写集成和/或单元测试。检测应用的装饰器的顺序是否正确或是否所有 ISomeService<T> 的实现确实在容器中注册。

我想提一下 Mark 博客中反对验证容器的 2 个具体论点。

It is easy to get into the situation that the container verifies, but still breaks at runtime.

我同意这一点，但我确实认为 Simple Injector 文档对如何处理此问题提供了一些很好的指导 here .

When doing convention over configuration it's easy to get registrations that shouldn't be in the container anyway.

我从来没有遇到过这个问题，因为我认为无论如何防止陷入这种情况是一种明智的做法。

回到问题:

尽管 Simple Injector 文档中的提示之一是使用抽象工厂，但在这种情况下我不会这样做。为已经存在的东西创建一个工厂，对我来说听起来很奇怪。也许这只是正确命名的问题，但为什么 AccountController 需要 AuthenticationFactory或 AuthenticationContext ?换句话说，由于 ASP.NET Identity 中的一些设计怪癖，应用程序为什么要知道我们在连接问题时有任何问题？

相反，通过调整 IAuthenticationManager 的注册我们可以在启动/验证时从新创建的 OwinContext 返回一个 Authentication 组件，并返回“正常”或配置 AuthenticationManager在运行时。这将消除对工厂的需求，并将责任转移到应该在的组合根。并让您注入(inject) IAuthenticationManager在您需要的任何地方，同时仍然可以拨打 .Verify() .

代码如下:

container.RegisterPerWebRequest<IAuthenticationManager>(() => 
    AdvancedExtensions.IsVerifying(container) 
        ? new OwinContext(new Dictionary<string, object>()).Authentication 
        : HttpContext.Current.GetOwinContext().Authentication); 

然而，更可靠的解决方案是不依赖于 IAuthenticationManager完全没有，因为依赖这个接口(interface)会导致我们违反了接口(interface)隔离原则，导致很难为其创建一个延迟创建的代理实现。

您可以通过定义一个符合您的需求且仅满足您需求的抽象来实现这一点。查看对 IAuthenticationManager 的身份模板调用这种抽象只需要 .SignIn()和 .SignOut()方法。然而，这会迫使你完全重构蹩脚的 AccountController您可以通过 Visual Studio 模板“免费”获得，这可能是一项艰巨的任务。