ASP.NET не может кэшировать нулевое значение
Я закончил тем, что использовал имена меток, содержащие значения для выражений падежа, как это было предложено AjV Jsy. В любом случае, я использую CALL вместо GOTO, чтобы перейти к правильному блоку регистра, и GOTO :EOF, чтобы вернуться назад. Следующий пример кода представляет собой полный пакетный скрипт, иллюстрирующий эту идею.
@ECHO OFF
SET /P COLOR="Choose a background color (type red, blue or black): "
2>NUL CALL :CASE_%COLOR% # jump to :CASE_red, :CASE_blue, etc.
IF ERRORLEVEL 1 CALL :DEFAULT_CASE # If label doesn't exist
ECHO Done.
EXIT /B
:CASE_red
COLOR CF
GOTO END_CASE
:CASE_blue
COLOR 9F
GOTO END_CASE
:CASE_black
COLOR 0F
GOTO END_CASE
:DEFAULT_CASE
ECHO Unknown color "%COLOR%"
GOTO END_CASE
:END_CASE
VER > NUL # reset ERRORLEVEL
GOTO :EOF # return from CALL
2 ответа
Базовый Кэш , скорее всего, Hashtable или Dictionary , геттеры которых не различают отсутствие значения в этом ключе или ноль значение в этом ключе.
Hashtable table = new Hashtable();
object x = table["foo"];
table.Add("foo", null);
object y = table["foo"];
Console.WriteLine(x == y); // prints 'True'
Рассмотрим элемент с пустым заполнителем, аналогичный DbNull.Value .
Чтобы немного прояснить принятый ответ Майкла Петротты (боюсь, слишком длинный для комментария), конкретные реализации CacheInternal (CacheSingle и CacheMultiple, последний из которых просто управляет несколькими экземплярами первый), который используется внутри общедоступного типа Cache для поддержки его методов Get, Add, Insert и т. д., для хранения полагаются на HashTable. Однако никогда не возникает вопроса о том, есть ли значение для определенного ключа в HashTable, потому что собственные (кешированные) значения не хранятся непосредственно в HashTable. Вместо этого HashTable заполняется уникальными объектами CacheEntry, которые обертывают кэшированные ключи и значения (CacheEntry фактически является производным от CacheKey, добавляя, помимо прочего, свойство Value на основе объекта; требование ненулевого значения можно найти в его конструкторе).
Основываясь на моем чтении кода, нет очевидной технической причины, по которой авторы требовали ненулевого значения CacheEntry.Value, за исключением того, что общедоступный объект Cache не предоставляет метод типа Contains или Exists и, конечно же, не раскрывает внутренние базовые объекты CacheEntry, он возвращает только значения CacheEntry. Итак, согласно ответу Майкла, без принуждения значений быть ненулевыми, пользователи объекта Cache не могут знать, существует ли конкретное значение ключа. Это также возможно, но потребует дополнительного чтения кода, чтобы точно знать, что довольно сложный подход, используемый внутри для управления зависимостями кэшированных объектов, истечением срока действия, событиями и обновлениями на месте записей HashTable, может каким-то образом полагаться на значения не является нулевым.