2013-03-12 6 views
6

Я парень vb.net и мне сложно читать C#. Я скомпилировал C# Dapper в DLL и использовал его в своем приложении. Моя основная проблема заключается в том, что мне нужно изменить источник для интеграции по умолчанию Framework Transaction Fault Handling Framework для SQL Azure в каждом запросе SQL.Как реализовать SQL Azure Transient Fault Handling Framework для Dapper?

Я могу добавить логику повторных попыток на уровне соединения, потому что это ОНТ вершина Dapper, но не на уровне выполнения запроса, который заделан в drapper классе.

Любой сделал это еще?

* UPDATE *

ли использование только ReliableSqlConnection сверху Dapper вызова будет обрабатывать повторов логики на выполнения, не запроса?

Вот пример кода повторов от MS с виной transietn hanling

using Microsoft.Practices.EnterpriseLibrary.WindowsAzure.TransientFaultHandling; 
using Microsoft.Practices.EnterpriseLibrary.WindowsAzure.TransientFaultHandling.AzureStorage; 
using Microsoft.Practices.EnterpriseLibrary.WindowsAzure.TransientFaultHandling.SqlAzure; 
using System.Data; 

... 

using (ReliableSqlConnection conn = new ReliableSqlConnection(connString, retryPolicy)) 
{ 
conn.Open(); 

IDbCommand selectCommand = conn.CreateCommand(); 
selectCommand.CommandText = 
    "UPDATE Application SET [DateUpdated] = getdate()"; 

// Execute the above query using a retry-aware ExecuteCommand method which 
// will automatically retry if the query has failed (or connection was 
// dropped). 
int recordsAffected = conn.ExecuteCommand(selectCommand, retryPolicy); 

} 

Вот это выполнить часть Dapper кода, то же имя используется, но я предполагаю, что это обычай выполнять функцию

private static int ExecuteCommand(IDbConnection cnn, IDbTransaction transaction, string sql, Action<IDbCommand, object> paramReader, object obj, int? commandTimeout, CommandType? commandType) 
    { 
     IDbCommand cmd = null; 
     bool wasClosed = cnn.State == ConnectionState.Closed; 
     try 
     { 
      cmd = SetupCommand(cnn, transaction, sql, paramReader, obj, commandTimeout, commandType); 
      if (wasClosed) cnn.Open(); 
      return cmd.ExecuteNonQuery(); 
     } 
     finally 
     { 
      if (wasClosed) cnn.Close(); 
      if (cmd != null) cmd.Dispose(); 
     } 
    } 
+0

Я могу подтвердить, что я, конечно, не - хотя лично я бы ожидайте, чтобы реализовать переходную обработку ошибок * вокруг * dapper, а не внутри dapper. –

+0

Да, но вокруг Dapper будет эффективным для самого соединения, но логика интеграции также ExecuteReaderWithRetry или NonQuery и т.д. В целом с повторной попытки на уровне выполнения должен быть интегрирован в щеголеватый, если я хорошо понимаю. –

+1

Да, но вы могли бы просто написать метод расширения «делать с повторной попыткой» ... –

ответ

2

Я бы рекомендовал обертывание повторной попытки вокруг Dapper, предпочтительно с использованием метода RetryPolicy.ExecuteAction. Таким образом, как открытый призыв к соединению и самой команде будет повторен с помощью политики TFH Retry:

Например:

 SqlRetryPolicy.ExecuteAction(() => 
     { 
      // Place Dapper ExecuteCommand here: e.g. 
      ExecuteCommand(conn, trans, ...) 
     }); 

 Смежные вопросы

  • Нет связанных вопросов^_^