Return Datareader von Datalayer in Using-Anweisung

Question

Wir haben eine Menge von Datenschicht Code, der diese sehr allgemeine Muster folgt:

public DataTable GetSomeData(string filter) 
{ 
    string sql = "SELECT * FROM [SomeTable] WHERE SomeColumn= @Filter"; 

    DataTable result = new DataTable(); 
    using (SqlConnection cn = new SqlConnection(GetConnectionString())) 
    using (SqlCommand cmd = new SqlCommand(sql, cn)) 
    { 
     cmd.Parameters.Add("@Filter", SqlDbType.NVarChar, 255).Value = filter; 

     result.Load(cmd.ExecuteReader()); 
    } 
    return result; 
} 

Ich denke, wir können ein wenig besser machen. Meine Hauptbeschwerde ist, dass alle Datensätze in den Speicher geladen werden müssen, auch für große Sets. Ich möchte in der Lage sein, die Fähigkeit eines DataReaders zu nutzen, nur einen Datensatz in Ram zu einem Zeitpunkt zu behalten, aber wenn ich den DataReader direkt zurückschicke, wird die Verbindung abgeschnitten, wenn der using-Block verlassen wird.

Wie kann ich dies verbessern, um die Rückgabe einer Zeile zu einer Zeit zu ermöglichen?

Answer 1

Noch einmal, der Akt des Komponierens meiner Gedanken für die Frage enthüllt die Antwort. Insbesondere der letzte Satz, in dem ich "eine Zeile nach der anderen" geschrieben habe. Mir wurde klar, dass es mir wirklich egal ist, dass es ein Datenleser ist, solange ich ihn Zeile für Zeile aufzählen kann. Das führt mich dies zu:

public IEnumerable<IDataRecord> GetSomeData(string filter) 
{ 
    string sql = "SELECT * FROM [SomeTable] WHERE SomeColumn= @Filter"; 

    using (SqlConnection cn = new SqlConnection(GetConnectionString())) 
    using (SqlCommand cmd = new SqlCommand(sql, cn)) 
    { 
     cmd.Parameters.Add("@Filter", SqlDbType.NVarChar, 255).Value = filter; 
     cn.Open(); 

     using (IDataReader rdr = cmd.ExecuteReader()) 
     { 
      while (rdr.Read()) 
      { 
       yield return (IDataRecord)rdr; 
      } 
     } 
    } 
} 

Dies funktioniert sogar besser, wenn wir bis 3,5 bewegen und können mit anderen LINQ-Operatoren auf die Ergebnisse starten, und Ich mag es, weil es uns aufstellt beginnen in Bezug auf ein Denken "Pipeline" zwischen jeder Ebene für Abfragen, die viele Ergebnisse zurückgeben.

Der Nachteil ist, dass es für Leser mit mehr als einer Ergebnismenge umständlich sein wird, aber das ist äußerst selten.

aktualisieren
Da ich mit diesem Muster zuerst im Jahr 2009 angefangen zu spielen, ich habe gelernt, dass es am besten ist, wenn ich es auch ein generischer IEnumerable<T> Rückgabetyp machen und fügen Sie einen Func<IDataRecord, T> Parameter, um den Datareader Zustand zu Business-Objekten konvertieren in die Schleife. Andernfalls kann es bei der verzögerten Iteration zu Problemen kommen, sodass Sie jedes Mal das letzte Objekt in der Abfrage sehen.

Answer 2

Was Sie wollen, ist ein unterstütztes Muster, werden Sie

cmd.ExecuteReader(CommandBehavior.CloseConnection); 

verwenden, und entfernen Sie beide using() ‚s Ihre GetSomeData() -Methode bilden. Die Ausnahmesicherheit muss vom Anrufer bereitgestellt werden, um ein Schließen des Lesers zu gewährleisten.

Answer 3

Ich war nie ein großer Fan davon, dass die Datenschicht ein generisches Datenobjekt zurückgibt, da dies den ganzen Punkt, den Code in seine eigene Schicht zu trennen, ziemlich auflöst (wie kann man Datenschichten abschalten, wenn die Schnittstelle nicht ist) nicht definiert?).

Ich denke, Ihre beste Wette ist für alle Funktionen wie diese, um eine Liste von benutzerdefinierten Objekten zurückgeben, die Sie selbst erstellen, und in Ihren Daten später rufen Sie Ihre Prozedur/Abfrage in einen Datenreader und durchlaufen durch das Erstellen der Liste.

Dies erleichtert die allgemeine Handhabung (trotz der anfänglichen Zeit zum Erstellen der benutzerdefinierten Klassen), erleichtert die Handhabung Ihrer Verbindung (da Sie keine damit verbundenen Objekte zurückgeben) und sollte dies tun sei schneller. Der einzige Nachteil ist, dass alles in den Speicher geladen wird, wie du erwähnt hast, aber ich würde nicht denken, dass dies ein Grund zur Sorge wäre (wenn es so wäre, würde ich denken, dass die Abfrage angepasst werden müsste).

Answer 4

In Zeiten wie diesen finde ich, dass Lambdas von großem Nutzen sein können.Betrachten Sie diese anstelle der Datenschicht uns die Daten geben, lassen Sie uns die Datenschicht unsere Datenverarbeitungsverfahren geben:

public void GetSomeData(string filter, Action<IDataReader> processor) 
{ 
    ... 

    using (IDataReader reader = cmd.ExecuteReader()) 
    { 
     processor(reader); 
    } 
} 

Dann wird die Business-Schicht würde es nennen:

GetSomeData("my filter", (IDataReader reader) => 
    { 
     while (reader.Read()) 
     { 
      ... 
     } 
    }); 

Answer 5

Der Schlüssel ist yield Stichwort.

Ähnlich wie Joel ursprüngliche Antwort, etwas mehr konkretisiert:

public IEnumerable<S> Get<S>(string query, Action<IDbCommand> parameterizer, 
          Func<IDataRecord, S> selector) 
{ 
    using (var conn = new T()) //your connection object 
    { 
     using (var cmd = conn.CreateCommand()) 
     { 
      if (parameterizer != null) 
       parameterizer(cmd); 
      cmd.CommandText = query; 
      cmd.Connection.ConnectionString = _connectionString; 
      cmd.Connection.Open(); 
      using (var r = cmd.ExecuteReader()) 
       while (r.Read()) 
        yield return selector(r); 
     } 
    } 
} 

Und ich habe diese Erweiterung Methode:

public static void Parameterize(this IDbCommand command, string name, object value) 
{ 
    var parameter = command.CreateParameter(); 
    parameter.ParameterName = name; 
    parameter.Value = value; 
    command.Parameters.Add(parameter); 
} 

So nenne ich:

foreach(var user in Get(query, cmd => cmd.Parameterize("saved", 1), userSelector)) 
{ 

} 

Dies ist voll generisch, passt zu jedem Modell, das den ado.net-Schnittstellen entspricht. The connection and reader objects are disposed after the collection is enumerated. Füllung Auf jeden Fall ein DataTable mit IDataAdapter ‚s Fill Methode can be faster than DataTable.Load