Question

我继承了一个相当大的C＃代码库，该代码库通过以下数据库操作方式散布了数百次：

using (SqlConnection connection = new SqlConnection(connectionString)) {
    SqlCommand command = new SqlCommand(queryString, connection);
    command.Connection.Open();
    command.ExecuteNonQuery();
}

但是，由于我无法控制的因素，数据库服务器非常恶劣，特别容易出现故障，因此很大一部分查询失败。鉴于访问数据库的这种特殊方式遍布代码中的任何地方，我如何在一个地方编写重试代码并将其应用于所有使用SqlCommand的地方？

一些想法：

我尝试覆盖SqlConnection / SqlCommand ExecuteNonQuery，因此我可以创建一个包装器版本。不好。 SqlConnection和SqlCommand是密封的C＃对象。
我可以创建一个名为MySqlConnection的容器类，其中包含一个.NET SqlConnection对象，然后创建我自己的ExecuteNonQuery，然后再重试SqlCommand.ExecuteNonQuery()几次。但是，这并不好，因为我必须实现每个SqlCommand函数并且训练其他人直接使用我的包装类而不是SqlCommand。遗憾的是，在这种情况下，用户教育不是可接受的解决方案。我被其他开发人员困在外包，经常更换，并且永远不会听我使用新SQL类的请求。
正如我之前提到的，我只是没有（在政治和技术上）访问数据库层。问题的根本原因只是一个糟糕的SQL服务器设置，但我无法解决该级别的问题。

我可以尝试其他选项吗？

Answer 1

假设你的外包'合作伙伴'有一点2x4和一张机票是不可能的，

你可能想看看像postharp（http://www.sharpcrafters.com/）这样的东西来制作一个面向方面的解决方案。基本上写一些可以挂钩到各种方法的代码。然后，您可以在SqlCommand上连接事件;处置，信息和状态更改可以产生一些有用的东西，如果你幸运。

我想说最好的解决方案是说服你的经理正确的代码修复是唯一理智的解决方案。我非常熟悉您的痛苦，但任何允许其他人编写软件的公司都需要负责验证该软件的质量，或者准备忽略低质量并接受后果。

识别真正糟糕的SQL性能代码可能会有一些里程，看看是否可以释放一些SQL服务器资源。

祝你好运

Answer 2

您是否想过简单的实用方法可以满足您的需求并成为进行数据库调用的标准？当然，这与你的包装思路一致，但它不会允许离岸团队的阻力，因为他们不必使用不同的类型。它可能只是将工作抽象到一个地方的原因。

我们需要集中我们的数据库处理等...向管理层抛出一些奇特的话语......然后你走了......

好像你可以从政治立场中取出那个吗？

Answer 3

如果你负担得起开销，一种选择就是编写某种“数据库代理”。

您的代码将指向代理（通过其连接字符串）。代理依次指向实际的DB（通过其连接字符串）。代理将拦截数据库请求，在真实数据库上执行它们，并返回结果。但是这样做，它可以实现一种算法，使查询更可靠（通过实现重试等）。

只是说。这将是一种在不改变代码的情况下实现重试的方法。

干净的方法来重试失败的System.Data.SqlClient操作

3 个答案: