Używanie mvc-mini-profilera z ADO.NET SqlConnection

Question

Próbuję użyć (niesamowitego) programu mvc-mini-profiler z istniejącym wcześniej kodowanym procesem SqlConnection (nie używamy EF ani L2S, tylko ADO .NET do SQL Server 2008). Szukam wskazówek, jak zintegrować dziedziczone typy ProfiledDb w tego rodzaju kodu.

var con = new SqlConnection("connectionstring"); 
var cmd = new SqlCommand(); 
cmd.CommandType = CommandType.StoredProcedure; 
cmd.Connection = con; 
cmd.CommandText = "SP_STORED_PROCEDURE_NAME"; 
cmd.Paramters.Add("recordsetid",SqlDbType.UniqueIdentifier).Value = recordsetid; 
var dSet = new DataSet(); 
var da = new SqlDataAdapter(cmd); 
da.fill(dSet); 
<parse DataSet> 

Każda pomoc tutaj dla nas użytkownicy spuścizna ADO.NET byłoby super, bo na powierzchni wydaje się, że SQL Profiler powinna mieć zastosowanie do tej sytuacji

Answer 1

Trzeba będzie zrobić to zakończyć połączenie i użyj fabryki DbConnection CreateCommand.

Podobnie jak w przypadku parametrów przejściowych, należy użyć podstawowych metod interfejsu i unikać takich rzeczy, jak SqlParameter, ponieważ nie są one zapakowane.

Więc:

var cnn = MvcMiniProfiler.Data.ProfiledDbConnection.Get(new SqlConnection(str)); 
var cmd = cnn.CreateCommand(); 
var param = cmd.CreateParameter(); 
... 

nie testowałem DataSets i DataAdapters, szczerze używam Dapper dla tego rodzaju rzeczy w tych dniach, ponieważ jest o wiele mniej gadatliwy. Jeśli to się uda, pamiętaj, by zgłosić kod Google.

Answer 2

Mam podobną sytuację, w której cały nasz SQL jest przechowywany w procedurach i po prostu mamy kod ADO.NET, który do nich woła. Mam również warstwę dostępu do danych, z której jestem zadowolony, więc nie podoba mi się pomysł przepisania jej na części, aby dostosować ją do MiniProfilera.

Więc kompromisem, na którym się zdecydowałem, było użycie standardowych połączeń MiniProfiler.Step() wokół wywołań procedur. Pomaga w moim przypadku, że wszystkie wywołania do ExecuteReader() i innych są częścią klasy bazowej, więc wiem, że wszystkie polecenia SqlCommands są wykonywane w ramach kilku podstawowych metod, więc łatwo było zmienić istniejący kod, aby wyglądał podobnie:

protected SqlDataReader ExecuteReader() 
{ 
    SqlDataReader reader = null; 

    // sqlComm is a member of a base class which this method is part of. I also 
    // happen to know that sqlComm.CommandText will always refer to a stored 
    // procedure name so it makes it easy to view in the results. 
    using (MiniProfiler.Current.Step(sqlComm.CommandText)) 
    { 
     try 
     { 
      sqlConn.Open(); 
      reader = sqlComm.ExecuteReader(); 
     } 
     catch (SqlException exception) 
     { 
      sqlConn.Close(); 
      // Error handling removed for brevity... 
     } 
    } 

    return reader; 
} 

Jestem pewien, że to nie jest tak dobre, jak odpowiedź Sama, bo jestem pewien, że niektórych szczegółów nie będzie w karcie wyników, ale działa to wystarczająco dobrze, żebym mógł analizować połączenia z bazami danych teraz z bardzo małymi zmianami w moim struktura kodu dostępu do danych.