Ich bin neu zu dapper und plane, es auf meinem neuen Projekt zu verwenden. Nach dem Lesen scheint das einzige Problem, das ich haben könnte, ConcurrentDictionary.
Dapper speichert Informationen über jede Abfrage, die es ausführt, damit es Objekte schnell materialisieren und Parameter schnell verarbeiten kann. Die aktuelle Implementierung speichert diese Informationen in einem ConcurrentDictionary-Objekt zwischen. Die Objekte, die es speichert, werden nie geleert. Wenn Sie SQL-Strings im laufenden Betrieb generieren, ohne Parameter zu verwenden, können Speicherprobleme auftreten. Wir können die Wörterbücher in einen LRU-Cache konvertieren.
Wie vermeide ich dieses Problem? Kann mir bitte jemand einen Code zeigen und mir sagen wie und wann man ihn spülen soll?
Nach den Kommentaren oben, hier ist ein Beispiel für on-the-fly:
var builder = new StringBuilder();
builder.AppendLine("SELECT Foo FROM Bar");
if (fisrtName != null || lastName != null)
builder.AppendLine("WHERE");
if (firstName != null)
builder.AppendLine(" Bar.FirstName = @Firstname");
if (firstName != null && lastName != null)
builder.Append(" AND");
if (lastName != null)
builder.AppendLine(" Bar.LastName = @LastName");
var sql = builder.ToString();
Wie Sie sehen können, wird die tatsächliche SQL, die dapper jetzt ausgeführt wird, davon firstName
ob firstName
und / oder lastName
null sind. Wenn beide null sind, erhalten Sie eine SQL-Zeichenfolge. Wenn nur firstName
nicht null ist, erhalten Sie einen anderen. Wenn nur lastName
nicht null ist, erhalten Sie noch einen anderen. Und schließlich, wenn beide nicht null sind, erhalten Sie eine vierte Permutation.
Dies ist, was mit "on-the-fly" gemeint ist - Dapper wird basierend auf diesen einzigartigen Permutationen cachen, und angesichts eines komplexeren Szenarios ist es leicht zu sehen, wie Sie mit sehr vielen verschiedenen Permutationen enden werden von denen würde unabhängig voneinander zwischengespeichert werden müssen.