Использование mvc-mini-profiler с ADO.NET SqlConnection - PullRequest
Новая
       18

Использование mvc-mini-profiler с ADO.NET SqlConnection

5 голосов
/ 27 июня 2011

Я пытаюсь использовать (удивительный) mvc-mini-profiler с некоторым уже существующим кодом хранимой процедуры SqlConnection (мы не используем EF или L2S, просто ADO.NET для SQL Server 2008).Я ищу несколько советов о том, как интегрировать унаследованные ProfiledDb типы в этот вид кода. 

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>

Любая помощь здесь для нас, унаследованных пользователей ADO.NET, была бы полезной, потому что на первый взглядПохоже, что SQL Profiler должен быть применим к этой ситуации

Ответы [ 2 ]

4 голосов
/ 28 июня 2011

Вам нужно будет завершить соединение и использовать фабрику DbConnection CreateCommand.

Аналогично для передачи параметров вам нужно будет использовать методы базового интерфейса и избегать таких вещей, как SqlParameter, потому что они не переносятся.

Итак: 

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

Я не тестировал DataSets и DataAdapters, честно говоря, в эти дни я использую Dapper для такого рода вещей, поскольку он гораздо менее многословен. Если он воспроизводится, не забудьте сообщить код Google.

3 голосов
/ 25 апреля 2012

У меня похожая ситуация, когда весь наш SQL находится в хранимых процедурах, и у нас просто есть код ADO.NET, который вызывает их. У меня также есть слой доступа к данным, которым я доволен, поэтому мне не нравится идея переписывать его просто для размещения MiniProfiler.

Итак, компромисс, на котором я остановился, заключался в использовании стандартных MiniProfiler.Step() вызовов вокруг вызовов процедур. В моем случае помогает, что все вызовы ExecuteReader() и др. Являются частью базового класса, поэтому я знаю, что все SqlCommands выполняются в нескольких базовых методах, поэтому мой существующий код было легко изменить, чтобы он выглядел примерно так: 

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;
}

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

...