Использование HttpContext.Current.Application для хранения простых данных

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

Хранение данных во встроенном объекте Cache ASP.NET имеет ряд существенных преимуществ, поскольку этот механизм фактически проверяет использование памяти и удаляет кэшированные данные в соответствии с некоторыми правилами.

Однако, если данные, которые вы хотите кэшировать, интенсивно используются в приложении и их размер не слишком велик (скажем, менее 1 МБ), вы можете сохранить их как глобальную переменную.

В ASP.NET глобальные переменные достигаются либо с помощью объекта Application, как вы описали в своем вопросе, либо путем написания общедоступных статических свойств / полей во внутреннем / общедоступном классе.

Вот мое решение статических свойств. Обратите внимание, что я использую объект блокировки, чтобы защитить внутренние данные от повреждения. Это выглядит так:

public class WhateverClass
{
  private static object theLocker = new object();
  private static YourDataType theData;
  public static YourDataType TheData
  {
    get
    {
      lock (theLocker)
      {
        return theData;
      }
    }
    set
    {
      lock (theLocker)
      {
        theData = value;
      }
    }
  }
}

Использование очень простое:

Первый раз в Application_Start:

protected void Application_Start()
{
    RegisterRoutes(RouteTable.Routes);

    WhateverClass.TheData = loadDataFromSql();
}

В любом контроллере:

var myData = WhateverClass.TheData;

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

HTH!

HttpContext.Current.Application - это, по сути, пережиток, необходимый для обратной совместимости с классическим ASP. По сути, это статическая хеш-таблица с классической семантикой блокировки ASP (Application.Lock / Application.UnLock).

В качестве слабо типизированной Hashtable вам нужно будет преобразовывать объекты, которые вы извлекаете:

MyObject myObject = (MyObject) HttpContext.Current.Application["myObject"];

В приложении ASP.NET, которое не является переходом от классического ASP, я бы предпочел использовать другие стандартные компоненты .NET, например:

• Статическое поле, использующее семантику блокировки .NET, если вам нужна блокировка (например, ключевое слово блокировки C # или экземпляр ReaderWriterLockSlim, в зависимости от ваших требований):

  статический MyObject myObject = LoadFromSql ();

• Кэш ASP.NET, который имеет богатую функциональность для управления истечением срока действия, зависимостями и т. Д.

Да, использование HttpContext.Current.Application подойдет для того, что вы делаете. Нет проблем.

HttpContext.Current.Application - это просто ссылка на статический глобальный объект HttpApplicationState в .NET для вашего веб-приложения, у которого должен быть один глобальный экземпляр на каждое веб-приложение. Сохраняя данные там, вы обеспечиваете быстрый, потокобезопасный доступ к вашим глобальным переменным. Обязательно заблокируйте их при обновлении значений, как в этом примере:

System.Web.HttpContext.Current.Application.Lock();
System.Web.HttpContext.Current.Application["WebApplicationPath"] = MyWebApplicationPath;
System.Web.HttpContext.Current.Application.UnLock();

Как уже упоминали другие, вы также можете создать серию статических классов в своей App_Code или другой папке и хранить там глобальные статические значения, а также ваши HttpContext.Current.Application значения, где их можно безопасно проверять на значения или обновлять из базы данных, или обновлять и проверяют друг друга, работая в тандеме. Обычно я создаю статический глобальный класс для помощи в управлении и извлечении хранимых мной переменных приложения. Таким образом, у вас есть как словарь состояний класса HttpApplicationState, так и статические объекты веб-приложения, работающие вместе, чтобы совместно использовать и поддерживать глобальные значения. (Имейте в виду, что каждый статический класс назначается для каждого рабочего процесса, и по умолчанию на многих веб-серверах / веб-приложениях IIS может быть до 10 WP в среднем. Поэтому сведите данные в статических типах к минимуму.)

Имейте в виду, что некоторые упомянутые фермы серверов не разделяют состояние приложения. Есть много способов справиться с этим. Я не поклонник кеша из-за того, что он может истечь, выйти из строя, устареть или быть поврежден. Более простое решение - просто использовать базу данных и строки запроса URL для связи между серверами и поддержания состояния. Удачи!

Если вы развертываете на одном веб-сервере, подход будет работать. Рассмотрим для этого объект Cache, поскольку он предоставляет больше возможностей для истечения срока действия, если вам нужна такая функциональность. (См. Сравнение, пусть и пожилого, здесь.)

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

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

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

Application_Start действительно запускается только при повторном использовании пула приложений, сбросе IIS или перезагрузке. Если вы обновляете эти значения нечасто, почему бы не сохранить их в своем web.config и получить к ним доступ таким образом?

При этом я не думаю, что в вашем подходе есть что-то неправильное. Хотя чаще я видел людей, использующих файлы конфигурации для редко изменяемых значений.