3

我想让重试逻辑透明，最好利用微软的瞬态故障处理应用程序块，而不是将我的代码的每个数据库访问片段包装到一个重试的函数中。我能做的是创建一个自定义类型的IDbConnectionFactory 自定义IDbConnection对象MySqlAzureConnection：

MySqlAzureConnection dbConn = myConnFactory.OpenDbConnection();
dbConn.Insert(new Employee { ...  });

我有两个选择：

  • 添加一个.Insert()方法来MySqlAzureConnection隐藏 OrmLite 的相同扩展方法，以提供我的重试逻辑。实际上，我.Insert()将包含与 OrmLite: call 完全相同的源代码dbConn.Exec()，但这.Exec()将是我提供重试逻辑的实现。
    问题是（为了确保我的程序中的查询和写入始终使用重试逻辑）这样我最终将复制和粘贴 [OrmLite][Read|Write]ConnectionExtensions 静态类中的所有 120 多个方法，只是为了扩展非常单一的行为dbConn.Exec()。听起来不太好。

  • 省略using ServiceStack.OrmLite;以确保不会调用 OrmLite 的非重试实现。在这种情况下，我该如何使用 OrmLite？我必须一直写完整的命名空间限定名称。听起来也很可怕。

编辑：

我意识到还有第三种选择：放弃重试逻辑“透明”的要求。换句话说，承认在使用 OrmLite 的每一段代码中显式使用了包装函数，并在该包装函数中实现重试逻辑。事实上，瞬态故障处理应用程序块 做同样的事情：引入ExecuteCommand()一个新方法（非标准IDbConnection）并让开发人员负责将其用作任何数据库访问代码的高级包装器。

虽然这个解决方案听起来比前两个更好，但我仍然不满意。Entity Framework (6.0) 已设法使这种弹性透明化，我期待在这里有一个类似的解决方案。（很容易连接到 OrmLite 的 ReadConnectionExtensions.Exec() 方法 - 如果它不是静态扩展方法。更好的是注入模块，就像在实体框架中所做的那样）。

4

1 回答 1

1

对此做了一些进一步的研究，结果发现，从 .Net 4.6.1 开始，瞬态错误处理现在已内置到 SqlConnection 中。因此，作为 Ormlite 的原始 Ado.net SqlConnection 基础，任何自定义方法都应该是不必要的。

担

于 2016-03-01T17:32:46.120 回答