15

我刚刚开始在一个项目中使用 Dapper，在过去的几年中主要使用的是 NHibernate 和 EF 等 ORM。

通常在我们的 Web 应用程序中，我们实现每个请求的会话，在请求开始时开始事务并在结束时提交。

在直接使用 SqlConnection / System.Transactions 时，我们是否应该做类似的事情？

StackOverflow 是如何做到的？

解决方案

听取@gbn 和@Sam Safron 的建议，我没有使用交易。在我的情况下，我只做读取查询，所以似乎没有真正的要求使用事务（与我被告知的隐式事务相反）。

我创建了一个轻量级会话接口，以便我可以使用每个请求的连接。这对我来说非常有益，因为使用 Dapper 我经常需要创建一些不同的查询来构建一个对象，并且宁愿共享相同的连接。

每个请求的连接范围和处理它的工作由我的 IoC 容器 (StructureMap) 完成：

public interface ISession : IDisposable {
    IDbConnection Connection { get; }
}

public class DbSession : ISession {

    private static readonly object @lock = new object();
    private readonly ILogger logger;
    private readonly string connectionString;
    private IDbConnection cn;

    public DbSession(string connectionString, ILogger logger) {
        this.connectionString = connectionString;
        this.logger = logger;
    }

    public IDbConnection Connection { get { return GetConnection(); } }

    private IDbConnection GetConnection() {
        if (cn == null) {
            lock (@lock) {
                if (cn == null) {
                    logger.Debug("Creating Connection");
                    cn = new SqlConnection(connectionString);
                    cn.Open();
                    logger.Debug("Opened Connection");
                }
            }
        }

        return cn;
    }

    public void Dispose() {
        if (cn != null) {
            logger.Debug("Disposing connection (current state '{0}')", cn.State);
            cn.Dispose();
        }
    }
}
4

2 回答 2

10

这就是我们所做的：

DB我们在一个名为的对象上定义一个静态调用Current

public static DBContext DB
{
    var result = GetContextItem<T>(itemKey);

    if (result == null)
    {
        result = InstantiateDB();
        SetContextItem(itemKey, result);
    }

    return result;
}

public static T GetContextItem<T>(string itemKey, bool strict = true)
{

#if DEBUG // HttpContext is null for unit test calls, which are only done in DEBUG
    if (Context == null)
    {
        var result = CallContext.GetData(itemKey);
        return result != null ? (T)result : default(T);
    }
    else
    {
#endif
        var ctx = HttpContext.Current;
        if (ctx == null)
        {
            if (strict) throw new InvalidOperationException("GetContextItem without a context");
            return default(T);
        }
        else
        {
            var result = ctx.Items[itemKey];
            return result != null ? (T)result : default(T);
        }
#if DEBUG
    }
#endif
}

public static void SetContextItem(string itemKey, object item)
{
#if DEBUG // HttpContext is null for unit test calls, which are only done in DEBUG
    if (Context == null)
    {
        CallContext.SetData(itemKey, item);
    }
    else
    {
#endif
        HttpContext.Current.Items[itemKey] = item;

#if DEBUG
    }
#endif
}

在我们的例子InstantiateDB中返回一个 L2S 上下文，但是在你的例子中它可能是一个开放的SQLConnection或其他的。

在我们的应用程序对象上，我们确保我们的连接在请求结束时关闭。

   protected void Application_EndRequest(object sender, EventArgs e)
   {
        Current.DisposeDB(); // closes connection, clears context 
   }

然后在您的代码中您需要访问数据库的任何地方，您只需简单地调用Current.DB并且东西会自动工作。#if DEBUG由于所有的东西，这也是单元测试友好的。

我们不会在每个会话中启动任何事务，如果我们在会话开始时这样做并且有更新，我们会遇到严重的锁定问题，因为锁定直到结束才会释放。

于 2011-06-02T00:33:47.420 回答
4

当您使用“write”调用调用数据库时，您只会在需要使用诸如TransactionScope之类的东西时启动 SQL Server 事务。

在最近的这个问题中查看一个随机示例：为什么即使 TransactionScope.Complete() 从未调用过，嵌套事务也会提交？

您不会打开连接并启动每个 http 请求的事务。仅按需提供。我很难理解为什么有些人主张在每个会话中打开一个数据库事务：当您查看数据库事务是什么时，这简直是白痴

注意：我并不反对这种模式本身。我反对调用 MSDTC 的不必要的、过长的客户端数据库事务

于 2011-06-01T14:13:26.037 回答