c# - 多个同步连接使UnitOfWork陷入困境

显然（并且很可能）我当前的UnitOfWork实现中存在一个缺陷，因为一次执行多个调用时出现连接错误。

例外：


  基础提供程序在打开时失败。


内部异常：


  连接未关闭。连接的当前状态是
  连接。
  
  这导致客户端上的HTTP 500响应。


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来启用与功能相关的数据的事务处理。而且也是根据客户需求，我别无选择。

最佳答案

您遇到的问题是，工作单元对象实际上是一个单例，因为您的IoC框架会在应用程序运行期间保持它不变。这意味着您的上下文也像在UoW内部一样保持为单例。因此，几乎可以肯定，您将获得对上下文的多个并发调用，这将引发异常。

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

关于c# - 多个同步连接使UnitOfWork陷入困境，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/33278413/