多个并发连接的UnitOfWork挣扎

例外：

The underlying provider failed on Open.

内部异常：

The connection was not closed. The connection’s current state is
connecting.

This results in a HTTP 500 response on the client side.

UnitOfWork实施

public class ScopedUnitOfWork : IUnitOfWork
{
    public Entities Context { get; set; }
    public UnitOfWorkState State { get; set; }

    public ScopedUnitOfWork(IEnvironmentInformationProvider environmentInformationProvider)
    {
        this.Context = new Entities(environmentInformationProvider.ConnectionString);
        this.State = UnitOfWorkState.Initialized;
    }

    public UowScope GetScope()
    {
        this.State = UnitOfWorkState.Working;

        return new UowScope(this);
    }

    public SaveResult Save()
    {
        if (this.State != UnitOfWorkState.Working)
            throw new InvalidOperationException("Not allowed to save out of Scope. Request an UowScope instance by calling method GetScope().");

        this.Context.SaveChanges();

        this.State = UnitOfWorkState.Finished;

        return new SaveResult(ResultCodes.Ok);
    }
}

使用单个UowScope可以解决此问题,但是鉴于当前情况,这是不可能的,因为每个请求都是完全独立的.实际上,每个请求都使用UoWScope,但是当UoW一次接收到许多呼叫时,显然会出错.

UoW是通过Unity IoC注入的,因此我想它实际上是一个单例.

问题

有没有办法适应UoW,这样就不会出现单独的高频请求？

最好我会解决此服务器端而不是客户端的任何提示？谢谢！

免责声明

我并不是说我完全了解UoW,所以我的实现可能需要改进,请保持谨慎:).对此肯定有任何改进！

更新

我知道EF上下文是一个UoW,我在域级别使用我的EF来启用与功能相关的数据的事务处理.而且也是根据客户需求,我别无选择.

但是,我认为您正在滥用UoW应该做什么的概念. UoW可以为一组事务提供一个容器.例如,假设您有一个电子商务平台.创建订单时,您将在订单表中插入一行,然后作为同一笔交易的一部分,您还将在订单项表中插入行,更新用户忠诚度积分等.因此,您应该在一个步骤中完成所有操作工作单元,提交它,然后销毁它.让IoC框架(在本例中为Unity)为每个会话创建工作单元.