【发布时间】：2016-03-02 01:32:46
【问题描述】：
我想让重试逻辑透明化，最好利用微软的Transient Fault Handling Application Block，而不是将我的每个数据库访问代码都包装到一个重试的函数中。
我能做的是创建一个自定义IDbConnectionFactory
生成 MySqlAzureConnection 类型的自定义 IDbConnection 对象：
MySqlAzureConnection dbConn = myConnFactory.OpenDbConnection();
dbConn.Insert(new Employee { ... });
我有两个选择：
将
.Insert()方法添加到MySqlAzureConnection以隐藏 OrmLite 的相同扩展方法，提供我的重试逻辑。 实际上我的.Insert()将包含完全相同的源代码 如在 OrmLite 中：致电dbConn.Exec()，但.Exec()将是 我提供重试逻辑的实现。
问题是（为了确保查询和写入 在我的程序中总是使用重试逻辑）这样我最终会 复制和粘贴所有 120 多种方法 [OrmLite][Read|Write]ConnectionExtensions 静态类， 只是为了扩展非常单一的dbConn.Exec()的行为。 听起来不太好。省略
using ServiceStack.OrmLite;以确保不重试 OrmLite 的实现不会被调用。在这种情况下，我该如何使用 或莱特？我必须一直写完整的命名空间限定名称。 听起来也很糟糕。
编辑：
我意识到还有第三种选择：放弃
重试逻辑是“透明的”。换句话说，承认显式使用
在使用 OrmLite 的每一段代码中都有一个包装函数，以及
在该包装函数中实现重试逻辑。事实上，Transient Fault Handling Application Block
做同样的事情：引入ExecuteCommand()，一种新方法
（IDbConnection 中的非标准）并使开发人员负责
将其用作任何数据库访问代码的高级包装器。
虽然这个解决方案听起来比前两个更好，但我仍然不是 满意。 Entity Framework (6.0) 已经成功地使 这种弹性透明，我期待着类似的 解决方案在这里。 （很容易连接到 OrmLite 的 ReadConnectionExtensions.Exec() 方法——如果它不是静态扩展 方法。更好的是一个可注入模块，如done in the Entity Framework) .
【问题讨论】：
-
您可以在 MySqlAzureConnection 上创建几个自定义的“写入”（插入、删除、更新）扩展方法，这些方法使用 OrmLiteConfig.DialectProvider.ToInsertRowStatement()/ToDeleteStatement() 等来生成Command.CommandText 属性的 SQL 语句。
-
对此也感兴趣 - 将创建一个 PR - 但是它会像覆盖 OrmLiteConnectionFactory 一样简单吗？ @mythz 你对最好的方法有看法吗？
标签： c# servicestack azure-sql-database ormlite-servicestack