Каков наилучший подход с глобальными переменными в приложениях ASP.Net?

Question

Что касается моих глобальных переменных и данных, я попадаю в дилемму относительно того, использовать ли HttpApplicationState или статические переменные. Какой наилучший подход?

В этом документе говорится, что нужно использовать статические переменные через httpapplicationstate: http://support.microsoft.com/default.aspx?scid=kb;en-us;Q312607

Однако, что мне нравится в HttpApplicationState (и System.Web.Caching.Cache), это то, что можно легко перечислять записи и выбирать, какие элементы удалять (для этой цели я создал глобальный CacheManager.axd) в то время как я не верю, что есть простой способ использования статических переменных (и даже тогда непонятно, что нужно сделать для их «повторной инициализации») без повторного использования пула приложений.

Есть ли какие-либо предложения по аккуратному универсальному способу обработки и управления глобальными объектами?

Спасибо, Марк.

Answer 1

Ваши инстинкты верны. Используйте System.Web.Caching. Встроенное управление кэшем берет на себя всю тяжелую работу, связанную с распределением памяти и устареванием устаревших или низкоприоритетных объектов.

Убедитесь, что для ключей кеша используется соглашение об именах, которое имеет смысл в будущем. Если вы начнете сильно полагаться на кеширование, вам нужно будет настроить таргетинг / фильтрацию разных ключей кеша по имени.

Answer 2

Как правило, по возможности старайтесь избегать глобального состояния в веб-приложениях. ASP.NET - это многопоточная среда, в которой несколько запросов могут обслуживаться параллельно. Если ваше глобальное состояние не является неизменным (только для чтения), вам придется решать проблемы, связанные с управлением изменяемым общим состоянием.

Если ваше общее состояние является неизменным, и вам не нужно его перечислять, то я не вижу проблем со статическими переменными.

Если ваше совместно используемое состояние является изменчивым / изменчивым, , то вы, вероятно, захотите создать абстракцию на основе любого нижележащего механизма, который вы выберете для хранения данных, чтобы обеспечить согласованность доступа и изменения этого общего состояния. и соответствует ожиданиям кода, который его потребляет. Вероятно, я бы также использовал системный кеш в таком дизайне, чтобы иметь возможность использовать функции истечения срока действия и зависимости, встроенные в службу кэширования (при необходимости).