Global.asax, глобальные переменные и редактирование с помощью кода

У меня есть два вопроса:

1) У меня есть несколько глобальных переменных для моего веб-сайта, объявленных в моем файле global.asax. Это простые, небольшие пары ключ/значение, и их всего несколько. Является ли это хорошей практикой для значений, которые малы и должны быть доступны почти на каждой странице моего веб-сайта? Хранение их в базе данных и требование поиска в базе данных, похоже, приведет к пустой трате ресурсов на значения, которые не меняются быстро.

2) Если одно из значений меняется раз в неделю, можно ли разрешить пользователю редактировать глобальную переменную с помощью формы или каким-либо другим способом?

Пример:

<script runat="server">

  Overloads Sub Application_Start(ByVal sender As Object, ByVal e As EventArgs)

      Application("default_scoring_id") = 3
      Application("week_current") = 3

  End Sub

</script>

В приведенном выше примере системе необходимо знать, в какой неделе (из 15) находится текущая дата. Таким образом, один раз в понедельник утром значение «week_current» необходимо изменить.

Я могу легко это сделать, но есть ли способ предоставить пользователю доступ к изменению этого значения, не касаясь кода?


asp.net global-variables asp.net-3.5 global-asax
person Randy Burgess    schedule 26.05.2009    source источник

Ответы (5)


arrow_upward
2
arrow_downward

Типичная практика заключается в том, чтобы поместить их в файл web.config, который можно редактировать. Эти значения <appSettings> будут доступны на каждой странице, но файл можно будет редактировать.

person John Saunders    schedule 26.05.2009

arrow_upward
1
arrow_downward

1) Хорошей практикой обычно является сохранение таких значений в файле web.config. См. здесь и здесь для некоторых руководств.

2) а) Если вы сохраните это в файле web.config, его можно будет легко обновить без необходимости перекомпиляции, и веб-приложение должно немедленно принять изменения.

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

person mundeep    schedule 26.05.2009
comment
Казалось бы, вы можете основывать номер недели на дате, но это проблематично, когда определенная работа задерживается, что предотвращает рутинную смену недели. К сожалению, мне нужно, чтобы пользователь сам определял точное время смены недели. - person Randy Burgess; 26.05.2009

arrow_upward
1
arrow_downward

Я бы подумал об использовании встроенного кеша (System.Web.Caching.Cache)

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

Внутри класса, который наследуется от BasePage, используйте данный объект Cache (например, Cache.Add(..)) и из других мест используйте HttpContext.Current.Cache (например, HttpContext.Current.Cache.Remove(Key))

person Tetraneutron    schedule 26.05.2009

arrow_upward
0
arrow_downward

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

lock(globalsharedobject) //This is C# code.
{
    Application("default_scoring_id") = 3;
}
person Kirtan    schedule 26.05.2009

arrow_upward
0
arrow_downward

Web.config - это способ .NET или способ ASP.NET, он не всегда самый эффективный или самый подходящий.

Ваш файл Global.asax — это гораздо больше, чем некоторые события, вы можете поместить статические данные в любой класс, который является подклассом System.Web.HttpApplication, и унаследовать его в файле Global.asax.

HttpSessionState и HttpApplicationState являются реликвиями классического времени ASP, и вам следует избегать их, потому что они не служат реальной цели.

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

Они должны быть статическими, потому что каждый HttpModule, а также экземпляр HttpApplication являются объединенными объектами, поэтому, чтобы избежать путаницы, убедитесь, что ваши постоянные данные хранятся в статическом или нескольких статических словарях. Но помните о проблемах параллелизма при изменении этих коллекций. Хорошая стратегия состоит в том, чтобы заблокировать объект только на то время, пока вы его изменяете, и убедиться, что вы не вызываете какой-либо другой код во время модификации коллекции, здесь может быть полезна простая идиома подкачки, это быстро и не сложно. - тупиковая гарантия.

person John Leidegren    schedule 26.05.2009