使用 WCF WebApi 实现工作单元

Question

我在使用新的 WCF WebApi 时面临的挑战之一是我无法干净地实现 UnitOfWork 模式。

作为快速背景，该模式的工作原理是在请求开始时启动一个工作单元，执行一些工作，然后回滚或提交该工作单元。

利用 HttpMessageHandler 功能设置“启动”工作单元的代码非常容易。并通过 Task<>库中，我可以编写一个在处理请求后执行的延续。但是，我不能总是确定是否发生了故障以便我可以回滚。

WCF 对故障具有低级支持，在传统的 WCF 服务端点中，您可以检查通道是否出现故障（例如，从 IMessageInspector 内部）。但 WebApi 似乎正在阻止这种行为。

WebApi 确实公开了 HttpErrorHandler 契约。但是，这是非常有限的，因为您无权访问实例上下文或服务实例，因此我无权访问我的工作单元。

我想知道这里还使用了哪些其他方法来实现工作单元模式？

Answer 1

佩德罗和达雷尔都给出了很好的建议。在我最终想出的解决方案中，我最终使用了一个消息处理程序：

public class UnitOfWorkHandler : DelegatingHandler 
{
    protected override Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken) 
    {
        var unitOfWork = new UnitOfWork();
        unitOfWork.Begin();
        return base.SendAsync(request, cancellationToken).ContinueWith(result => 
            {
                if (result.Result is HttpResponseMessage && ((HttpResponseMessage)result.Result).IsSuccessStatusCode) 
                {
                    unitOfWork.Commit();
                } 
                else 
                {
                    unitOfWork.Rollback();
                }
                return result.Result;
            });
    }
}

我会使用 Darrel 的建议来存储对 HttpRequestMessage 属性集合上的 UnitOfWork 的引用，但是由于任务延续是作为闭包实现的，所以我可以简单地引用我在其外部范围中创建的工作单元。

Answer 2

有一个挂在 HttpRequestMessage 上的属性集合，您可以将工作单元对象填充到其中，以便可以在返回路径上访问它。

Answer 3

1）您可以使用操作处理程序或消息处理程序来设置和拆除工作单元（UoW）
a) 消息处理程序具有端点范围，因此它们适用于所有操作。
b) 操作处理程序具有操作范围，并且如果只有某些操作需要 UoW，则可能会很有用。

2) 正如 Darrel 所说，有关 HTTP 请求的所有上下文信息都应添加到 HttpRequestMessage 属性包中。

3) 在Web API 模型中，不存在错误（错误是SOAP 构造）。您可能应该依赖 HTTP 响应状态来检查操作是否成功（2xx）或失败（4xx、5xx）。

Answer 4

我的场景：

• 控制器（需要存储库）
• 存储库（需要IUnitOfWork）
• 操作过滤器（也需要IUnitOfWork）

问题：

DI 动作过滤器已经困扰我一段时间了。我喜欢约瑟夫的方法，我真的很喜欢。在每个请求之前创建（或开始）我的工作单元对我来说似乎很自然。由于操作过滤器可以被缓存，因此它们不使用与控制器相同的依赖范围。 因此，需要 Setter 注入。

解决方案：

以与没有操作过滤器时相同的方式配置结构图。像这样的东西：

public class NHibernateRegistry : Registry
{
    public NHibernateRegistry()
    {
        For<ISessionFactory>).Singleton().Use(
            NhSessionFactoty.Instance.SessionFactory);
        For<IUnitOfWork>().HybridHttpOrThreadLocalScoped().Use<NhUnitOfWork>();
        For(typeof(IBaseRepository<,>)).Use(typeof(BaseRepository<,>));
    }
}

NhSessionFactoty封装了我的休眠配置，并允许获取单个ISessionFactory在我的应用程序中使用。
NhUnitOfWork 实现我的 IUnitOfWork 接口，并处理会话和事务管理。

操作过滤器属性（改编自 Joseph 的回答）：

public class UnitOfWorkAttribute : ActionFilterAttribute
{
    public override void OnActionExecuting(HttpActionContext actionContext)
    {
        /* Check this line, it's a problem solver!! */
        var uow = (IUnitOfWork)actionContext.Request.GetDependencyScope()
            .GetService(typeof(IUnitOfWork));
        uow.Begin();
    }

    public override void OnActionExecuted(
        HttpActionExecutedContext actionExecutedContext)
    {
        var uow = (IUnitOfWork)actionExecutedContext.Request.GetDependencyScope()
            .GetService(typeof(IUnitOfWork));

        try
        {
            if (actionExecutedContext.Exception == null)
                uow.Commit();
            else
                uow.Rollback();
        }
        catch
        {
            uow.Rollback();
            throw;
        } 
        /*finally
        {
            uow.Dispose();
        }*/ // Resources are released in Application_EndRequest (Globals.cs)
    }
}

最后是我的基本控制器：

[UnitOfWork]
public class ControllerBaseUow : ApiController {}
/* Then, in my case, I inject Repositories via contructor */

它可以工作，因为在 OnActionExecuting< /code> 我们得到了控制器中使用的相同依赖范围。

然后像平常使用 DI 一样工作:)