在自托管 Web Api 中检测上下文

Question

在我当前的项目中，我有一个定期运行任务的 Windows 服务 (TopShelf/Quartz.net)。我不想为 Web 服务创建单独的项目，而是想使用 OWIN 中提供的自托管功能将其添加到 Windows 服务中。这还有一个额外的好处，就是不需要在 IIS 中部署。

当我要实现我的数据访问层 (DAL) 时，我会遇到问题。

我所有的数据库操作都是在一个存储在请求状态的 UnitOfWork 中完成的，最后有一个提交/回滚。上下文决定了 UnitOfWork 的生命周期（请求状态）。在控制台应用程序中，我将使用 PerThreadRequest 状态。在网络环境中，我有一个 PerHttpRequestState。这意味着 UnitOfWork 的范围是每个线程或每个 HttpRequest。

然而，在我当前的项目中，我混合了控制台（Quartz 作业）和 Web（Web api 调用）。它们都需要使用 DAL，但不能使用与另一个上下文相同的请求状态。

我可以手动解决这个问题。当使用来自石英作业的 DAL 时，让它使用 PerThreadRequestState，当使用来自 web api 调用的 DAL 时，使用 PerHttpRequestState 但这是一个混乱的解决方案。 使用 DAL 时，它应该检测到它正在运行的上下文并做出相应的反应。

但是我该如何检测上下文呢？

Answer 1

我会建议这样的事情，使用 Castle Windsor（虽然原理与其他 IOC/DI 框架相同）

if(HttpRuntime.AppDomainAppId != null) //it's a web app
{
    container.Register(
         Component.For<IUnitOfWork>().ImplementedBy<PerHttpRequestState>());
}
else //it's a windows app
{
    container.Register(
         Component.For<IUnitOfWork>().ImplementedBy<PerThreadRequestState>());
}

话虽如此，在线程生活方式上使用 UoW 有一些注意事项：

• 首先，您必须确保您的 UoW 是线程安全的（如果两个或更多作业最终同时访问 UoW，会发生什么情况？）
• 更重要的是，Quartz.NET 内部使用了一个 ThreadPool，因此它不一定会在每次启动作业时创建一个新线程，而是重用一个现有的线程。这会导致泄漏；您的 UoW 实际上可以在工作之间共享。您可能想要的是使用自定义 PerQuartzJob 生活方式。

但是，这两者都取决于您打算将石英服务用于何种用途。如果您没有很多长期运行的、可能重叠的 CRUD 作业，那么它们就不是问题了。