コードのデータベースにアクセスするすべての部分を再試行する関数にラップするのではなく、理想的には Microsoft のTransient Fault Handling Application Blockを利用して、再試行ロジックを透過的にしたいと考えています。私ができることは、タイプのIDbConnectionFactory
カスタムIDbConnectionオブジェクトを生成するカスタムを作成することですMySqlAzureConnection:
MySqlAzureConnection dbConn = myConnFactory.OpenDbConnection();
dbConn.Insert(new Employee { ... });
2 つの選択肢があります。
OrmLite の同じ拡張メソッドを非表示にする
.Insert()メソッドを追加して、再試行ロジックを提供します。MySqlAzureConnection実際に.Insert()は OrmLite: call とまったく同じソース コードが含まれますdbConn.Exec()が、それ.Exec()が再試行ロジックを提供する実装になります。
問題は、(私のプログラムのクエリと書き込みが常に再試行ロジックを使用することを確認するために) この方法では、[OrmLite][Read|Write]ConnectionExtensions 静的クラスの 120 以上のメソッドすべてをコピー & ペーストすることになることです。単一の の動作を拡張するだけdbConn.Exec()です。あまりいい音ではありません。using ServiceStack.OrmLite;OrmLite の再試行しない実装が呼び出されないようにするために省略します。この場合、どのように OrmLite を使用できますか? 常に完全な名前空間修飾名を記述する必要があります。ひどいですね。
編集：
3 番目の選択肢があることに気付きました。再試行ロジックが「透過的」であるという要件を放棄することです。つまり、OrmLite を使用するすべてのコードでラッパー関数を明示的に使用することを認め、そのラッパー関数に再試行ロジックを実装します。実際、Transient Fault Handling Application Block
はまったく同じことを行います。ExecuteCommand()新しいメソッド ( では非標準IDbConnection) を導入し、データベースにアクセスするコードの高レベル ラッパーとしてそれを使用する責任を開発者に負わせます。
このソリューションは最初の 2 つのソリューションよりも優れているように聞こえますが、私はまだ満足していません。Entity Framework (6.0) は、この回復力を透過的にすることに成功しており、同様のソリューションを期待しています。(静的拡張メソッドでなければ、OrmLite の ReadConnectionExtensions.Exec() メソッドに接続するのは簡単です。Entity Framework で行われているように、注入可能なモジュールの方がさらに優れています)。