如何通过依赖注入传递 Web API 请求？

Question

我有一个 Web API 应用程序，其中控制器通过依赖注入 (Unity) 将服务/存储库等注入其中。假设我有一个 IStuffService 需要当前请求的 IPrincipal（或围绕它的包装器）。

Web API 的问题似乎是当前请求/用户的唯一可靠来源是ApiController 的实例 上的Request 属性.由于 Web API 的同步特性，不能保证任何静态内容（无论是 HttpContext.Current、CallContext.Get/SetData 或 Thread.Get/SetData）都在同一个线程上。

我如何可靠地确保特定于请求的上下文通过依赖项传递，更重要的是，该操作在整个操作过程中始终保持正确的IPrincipal？

两种选择：

1. 每个需要 IPrincipal 的方法都将它作为方法的参数 - 这是最可靠的方法，但它也要求我在每个方法签名中都有那个东西
2. 将 IPrincipal 注入到服务的 ctor 中，在每个请求上启动对象图的新实例，使用 Unity 中的 DependencyOverride：container.Resolve(opType, new DependencyOverride(typeof(IPrincipal), principal))

选项 2 意味着我的方法签名是干净的，但这也意味着我需要确保所有依赖项都使用 TransientLifetimeManager，而不是单例甚至每线程。

有没有比我没有看到的更好的解决方案？

Answer 1

来自cmets：

@MichaelStum，我相信 HttpContext.User 应该正确流动 跨 async/await（在同一个 HTTP 请求中）。不适合你吗？ – Noseratio 17 小时前

@Noseratio 查看其他答案 - 在 .net 4.0 中，它绑定到 当前线程并且没有得到适当的维护。似乎在4.5中， 这可能是固定的。也就是说， HttpContext.Current 仍然不是那个 适用于 Web API，因为在自托管的 API 上没有 HttpContext.Current。

AFAIK，无论如何，在 ASP.NET 4.0 中都没有对 async/await 的适当支持（您可能可以使用 Microsoft.Bcl.Async 获得语言支持，但没有 ASP.NET 运行时支持，因此您必须使用 @987654321 @ 来实现 TAP 模式）。

也就是说，我 99% 确定 Thread.CurrentPrincipal 仍会在 ASP.NET 4.0 中正确地流经 await 延续。那是因为它作为ExecutionContext 流的一部分进行流动，而不是通过同步上下文。至于HtttContext.Current.User，我不确定它是否会在 ASP.NET 4.0 中正确流动（尽管它在 ASP.NET 4.5 中确实如此）。

我已重新阅读您的问题，但可以找到关于 Thread.CurrentPrincipal 未正确处理的明确投诉。您是否在现有代码中遇到过这个问题（如果有，可能是 ASP.NET 中的一个错误）？

以下是相关问题的列表，由 Stephen Cleary 提供了一些深刻的见解：

• Understanding context in C# 5 async/await

• Why is an "await Task.Yield()" required for Thread.CurrentPrincipal to flow correctly?

• Using ASP.NET Web API, my ExecutionContext isn't flowing in async actions

Scott Hanselman 的这篇博文也与此相关，尽管他谈到了 WebForms：

• System.Threading.Thread.CurrentPrincipal vs. System.Web.HttpContext.Current.User or why FormsAuthentication can be subtle

如果您担心自托管场景，我相信Thread.CurrentPrincipal 仍会在那里正确流动（一旦设置为正确的身份）。如果您想流动任何其他属性（those which get automatically flowed with ExecutionContext 除外），您可以推出自己的同步上下文。另一种选择（不太好，IMO）是use custom awaiters。

最后，如果您遇到实际需要跨 await 延续的线程亲和性的情况（很像在客户端 UI 应用程序中），您也有这样的选择（同样，使用自定义同步上下文）：

• How to use non-thread-safe async/await APIs and patterns with ASP.NET Web API?

Answer 2

最终的答案是我们的 IoC 容器需要更改以更好地支持 async/await。

背景：

在 .NET 4 和 .NET 4.5 之间，围绕此问题的 async/await 行为发生了变化。在 .NET 4.5 中引入了SynchronizationContext，它将正确恢复HttpContext.Current（请参阅http://msdn.microsoft.com/en-us/magazine/gg598924.aspx）。但是，使用.ConfigureAwait(false)（参见http://msdn.microsoft.com/en-us/magazine/jj991977.aspx 中的“配置上下文”）通常是最佳实践，并且特别要求不保留上下文。在这种情况下，您仍然会遇到您描述的问题。

答案：

我能够在自己的代码中提出的最佳答案是确保在 Web 请求的早期请求来自 HttpContext.Current（在您的情况下为 IPrincipal）的依赖项，以便加载放入容器中。

我对 Unity 没有任何经验，但在 Ninject 中这看起来像：

kernal.Bind<IPrincipal>().ToMethod(c => HttpContext.Current.User).InRequestScope();

然后我会确保在您丢失上下文之前在 Web 请求的早期加载 IPrincipal。在 BeginRequest 中或作为控制器的依赖项。这将导致 IPrincipal 被加载到该请求的容器中。

注意：在某些情况下这可能不起作用。我不知道 Unity 是否有这个问题，但我知道 Ninject 有。它实际上使用 HttpContext.Current 来确定哪个请求处于活动状态。因此，如果您稍后尝试从容器中解析某些内容，例如服务定位器或工厂，那么它可能无法解析。

Answer 3

我知道这是一个老问题，我曾使用选项一（在问题中）并且它有效。

更新：我删除了我的答案，因为我意识到我发布了一些不起作用的东西。 给您带来不便，敬请见谅。

Answer 4

如何可靠地确保传递特定于请求的上下文 通过依赖关系，更重要的是，操作保留 整个操作过程中的 IPrincipal 是否正确？

我认为你不应该这样做。您的服务比您的 Api 控制器低层。你的服务不应该依赖于任何与高层相关的类，否则你的服务不能被重用，例如：当你需要在上面构建一个win forms应用程序时现有服务。

IPrincipal 不适合注入我们的服务，因为它与网络应用程序相关。当我们将此信息传递到较低层（服务）时，我们应该传递我们的 neutral-classes 或仅传递一个 userId 以将我们的服务与使用它的应用程序。

您应该为用户定义自己的类以及与请求相关的任何内容，以便在我们的服务层中使用，因为它更与域相关。这样一来，您的服务层就与应用层（Web、win 表单、控制台等）无关：

public class AppPrincipal : IAppPrincipal
{
   public int UserId { get; set; }
   public string Role { get; set; }
   //other properties
   public AppPrincipal() {

   }
   public AppPrincipal(int userId, string role):this() {
       UserId  = userId;
       Role = role;
   }
}

然后，您可以在 Web 应用程序中将 IAppPrincipal 注册为每个请求范围，并使用您的 IPrincipal 填充所有属性。这将在任何await/async 调用之前为您的整个对象图初始化您的IAppPrincipal。 Unity 示例代码：

public void RegisterTypes(IUnityContainer container)
{
    container.RegisterType<IAppPrincipal>(
                new PerRequestLifetimeManager(),
                new InjectionFactory(c => CreateAppPrincipal()));
}
public IAppPrincipal CreateAppPrincipal()
{
    var principal = new AppPrincipal();
    principal.UserId = //Retrieve userId from your IPrincipal (HttpContext.Current.User)
    principal.Role = //Retrieve role from your IPrincipal (HttpContext.Current.User)
    return principal;
}

这里的关键是我们已经将我们的服务层与网络解耦了。如果您需要重用服务层来构建 Windows 窗体或控制台应用程序，您可以将 IAppPrincipal 注册为单例并以不同方式填充它。

我们不需要处理像async/await这样的平台相关问题