多租户，帮助理解 WorkContext 的概念

Question

在尝试了解多租户环境的工作原理时，我想到了 WorkContext 的概念。

简介：

在多租户环境中，租户是共享相似功能的客户端，并在 ROOT 应用程序的单个实例下运行。为了能够添加特定于租户的功能，我得出了一个结论，即 依赖注入 是适合我的情况的解决方案。

每个租户都应该有自己的 IoC 容器，以便能够在运行时解决其依赖关系。

但是在尝试实施该理论时，我在包装所有租户特定数据方面遇到了一些麻烦。

在挖掘互联网时，似乎必须存在某种 TenantContext。所以每个租户都有自己独立的上下文。

问题是我不明白这样一个 Context 的真正 LifeCycle。

问题一：

什么是特定于租户的 WorkContext 的生命周期图，我应该将它存储在哪里，应该何时创建/处置它？

注意：如果提供了问题1，则无需回答上述问题。

突然间，我发现果园计划似乎是真正的杰作。在 Orchard 内部，我所说的 Context 叫做WorkContext。

我正在尝试理解 Orchard Project 中 WorkContext 的概念。据我了解，以下是关于 WorkContext 的一些想法：

1. WorkContext 是每个请求的生命周期对象。
2. 存储在HttpContext.Items中（也有线程静态实现..）。
3. 它封装了租户 IoC 范围（ShellContext -> ShellContainer）。
4. 通过IWorkContextAccessor访问。

我不明白的是：

问题2：

为什么我们需要在路由的 DataTokens 中包含 IWorkContextAccessor 实例，如下所示：routeData.DataTokens["IWorkContextAccessor"] = _workContextAccessor;？这真的有必要吗？

Answer 1

有点大问题:-)。

首先，WorkContext 或多或少是 HTTP 上下文的抽象。 WorkContext 只要其工作上下文范围存在（参见IWorkContextAccessor，您可以使用它来创建工作上下文范围），因此实际上每个请求可以有多个工作上下文，并且您也可以拥有独立于请求的工作上下文（这发生在后台任务中）。

因此，此类工作上下文是外部管理的上下文，因此必须以某种方式与它们的作用域一起“旅行”，直到后者终止：在 Orchard 中，WC 要么在 HTTP 上下文中携带，要么在线程静态字段中携带（什么是 @ 987654321@).

因此基本上工作上下文范围是常用的最低依赖范围。它还有一个父级，即 shell 的作用域：这是 shell 上下文（或更准确地说，它的生命周期作用域）。您可以通过IOrchardHost.GetShellContext() 访问外壳（大多数情况下等于租户）的上下文。工作上下文范围实际上是从 shell 上下文的生命周期范围创建的。

这也有一个父 BTW，它是应用程序范围的 HostContainer。

大多数情况下，您不必自己管理 WC，因为围绕请求和后台任务的环境 WC 已为您管理。

关于您的第二个问题：我对此并不完全确定，但 AFAIK 将 WCA 传递给 routeData 只是作为一种解决方法，以便能够从 HTML 帮助程序和属性等奇怪的地方访问它（以及 Orchard 服务）不通过 DI 容器解析。

编辑：也将此添加到 Dojo 库中，经过编辑和改进：http://orcharddojo.net/orchard-resources/Library/Wiki/WorkContext