dapper.net, как сбросить ConcurrentDictionary?

Я новичок в dapper и планирую использовать его в своем новом проекте. После прочтения кажется, что единственная проблема, с которой я могу столкнуться, это ConcurrentDictionary.

Dapper кэширует информацию о каждом выполняемом запросе, что позволяет ему быстро материализовать объекты и быстро обрабатывать параметры. Текущая реализация кэширует эту информацию в объекте ConcurrentDictionary. Объекты, которые он хранит, никогда не сбрасываются. Если вы генерируете строки SQL на лету без использования параметров, возможно, вы столкнетесь с проблемами памяти. Мы можем конвертировать словари в кэш LRU.

Как избежать этой проблемы? Может кто-нибудь, пожалуйста, покажите мне какой-нибудь код, скажите мне, как и когда его сбрасывать?


dapper concurrentdictionary
person qinking126    schedule 04.05.2012    source источник
comment
Итак, вы генерируете строки SQL «на лету»?   -  person Kirk Woll    schedule 04.05.2012
comment
что значит генерировать строки SQL "на лету"? Можете ли вы привести пример?   -  person qinking126    schedule 04.05.2012
comment
Строка SQL - вы динамически создаете ее, используя StringBuilder? Или это скорее постоянная строка, объявленная как var sql = @"SELECT Foo FROM Bar"?   -  person Kirk Woll    schedule 04.05.2012
comment
Я не использую stringbuilder, он медленный. однако я использую параметр в своем запросе: Query‹Thing›(выберите * из Thing, где Name = @Name, new {Name = new DbString { Value = abcde, IsFixedLength = true, Length = 10, IsAnsi = true }); это считается на лету или нет?   -  person qinking126    schedule 05.05.2012
comment
Это не на лету, и это выглядит хорошо. Я подозреваю, что это не причина вашей проблемы с производительностью. Можете ли вы подробнее рассказать о симптомах проблемы с производительностью? Например, намного ли быстрее выполняется тот же запрос, если он выполняется непосредственно на сервере базы данных? (через SQL Server Management Studio или что-то еще)   -  person Kirk Woll    schedule 05.05.2012
comment
кирк, спасибо большое. мое приложение в порядке. действительно нет никаких проблем. просто хочу узнать правильно ли я делаю. Просто чтобы не делать это на лету. Можете ли вы привести пример на лету?   -  person qinking126    schedule 05.05.2012
comment
Я добавил ответ, чтобы уточнить.   -  person Kirk Woll    schedule 05.05.2012

Ответы (1)


arrow_upward
2
arrow_downward

Согласно комментариям вверху, вот пример «на лету»:

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();

Как видите, фактический SQL, который теперь будет выполнять dapper, будет отличаться в зависимости от того, являются ли firstName и/или lastName нулевыми. Если оба равны нулю, вы получите одну строку SQL. Если только firstName не равно нулю, вы получите другое. Если только lastName не равно нулю, вы получите еще один. И, наконец, если оба не равны нулю, вы получите четвертую перестановку.

Это то, что подразумевается под «на лету» — dapper будет кэшировать на основе этих уникальных перестановок, и, учитывая более сложный сценарий, легко увидеть, как вы получите большое количество различных перестановок, все из которых необходимо кэшировать независимо.

person Kirk Woll    schedule 04.05.2012
comment
извините, последний вопрос. запрос, который я разместил ранее, если я изменил значение имени. это новая перестановка? есть ли способ проверить, слишком ли много запросов и нужно ли очищать ConcurrentDictionary? - person qinking126; 05.05.2012
comment
Когда вы используете заполнители (например, where Name = @Name), то изменение значения, которое вы передаете (например, new {Name = new DbString { Value = "abcde", IsFixedLength = true, Length = 10, IsAnsi = true })), совершенно нормально, и именно так предполагается использовать dapper. - person Kirk Woll; 05.05.2012