Usando mvc-mini-profiler con ADO.NET SqlConnection

Question

Estoy intentando utilizar el (increíble) mvc-mini-profiler con algún código de procedimiento almacenado SqlConnection preexistente (no usamos EF o L2S, solo ADO .NET a SQL Server 2008). Estoy buscando orientación sobre cómo integrar los tipos ProfiledDb heredados en este tipo de código.

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> 

Cualquier ayuda aquí para nosotros los usuarios legado ADO.NET sería grande porque en la superficie parece que el Analizador de SQL debe ser aplicable a esta situación

Answer 1

Usted tendrá que hacer es envolver su conexión y use la fábrica DbConnection CreateCommand.

mismo modo para pasar parametros que tendrá que utilizar los métodos de interfaz de base, y evitar cosas como SqlParameter porque no se envuelve.

Así: conjuntos de datos y DataAdapters

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

no he probado, la verdad es que utilizan Dapper para este tipo de cosas en estos días ya que es mucho menos detallado. Si se juega, asegúrese de informar el código de Google.

Answer 2

Tengo una situación similar en la que todos nuestros SQL están en procedimientos almacenados y simplemente tenemos el código ADO.NET que los llama. También tengo una capa de acceso a datos con la que estoy contento, así que no me gusta la idea de tener que reescribir fragmentos simplemente para acomodar MiniProfiler.

Por lo tanto, el compromiso que establecí fue utilizar las llamadas estándar MiniProfiler.Step() en las llamadas a procedimientos. Esto ayuda en mi caso de que todas las llamadas a ExecuteReader() y otros son parte de una clase base, así que sé todos SqlCommands se ejecutan dentro de unos métodos de base, así que fue fácil cambiar el código existente para tener un aspecto similar a este:

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

Estoy seguro de que esto no es tan bueno como la respuesta de Sam, ya que estoy seguro de que faltan algunos detalles en la pestaña de resultados, pero funciona lo suficientemente bien como para analizar las llamadas a la base de datos ahora con muy pocos cambios en mi estructura de código de acceso a datos.