Статические переменные в asp.net/C#

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

Так что вообще практика программирования не использует статические переменные в разработке обычного веб-приложения?

Статические переменные не используются вообще, как выражение GOTO/ключевое слово, существуют обширные ограничения на их использование и предпочтительно вообще не используются? Затем в каких случаях мы используем статическое ключевое слово?

Тогда у меня есть это требование, чтобы определенная переменная была инициализирована только один раз в определенном webform.aspx.cs, и область действия должна ограничиваться только этим конкретным .aspx.cs и тем конкретным пользователем, который зарегистрировался в? Как мне выполнить это требование? Если возможно, кто-нибудь проиллюстрирует это кодом?

Ответ 1

Лично я стараюсь избегать статических переменных как можно больше. Они делают код трудным для unit test, а также могут вводить тонкие ошибки из-за одновременного доступа и условий гонки.

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

Ответ 2

Я считаю, что ваша интерпретация static неверна.

Используйте статический модификатор, чтобы объявить статический член, который принадлежит типа, а не объект.

Другими словами, для всех конкретных экземпляров класса есть только один экземпляр этого элемента.

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

Этот вопрос Programmers.SE, вероятно, вас интересует.

Ответ 3

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

Тогда у меня есть это требование, чтобы определенная переменная была инициализирована только один раз в определенном webform.aspx.cs, и область действия должна ограничиваться только этим конкретным .aspx.cs и тем конкретным пользователем, который зарегистрировался в? Как мне выполнить это требование? Если возможно, кто-нибудь проиллюстрирует это кодом?

Для этого требования я бы предложил вам взглянуть на разъяснение требования:

это один раз для пользователя? Если это так, посмотрите на объект Session, предоставляемый ASP. Пример кода для Session: http://msdn.microsoft.com/en-us/library/ms972429.aspx
или это один раз на страницу для пользователя? то есть, если один и тот же пользователь открывает два браузера на одной странице, то будет ли у пользователя два объекта? Если да, то посмотрите на ViewState на странице. Обзор ViewState http://msdn.microsoft.com/en-us/library/ms972976.aspx

Лично я предпочитаю использовать Session - с ViewState, это очень легко для вещей, чтобы пойти не так, и когда они идут не так, это может быть очень сложно отладить!

объяснение: "когда они ошибаются, это может быть очень сложно отладить" - ViewState может быть настроен на работу несколькими способами, но в целом он настроен на работу, сериализуя объекты на клиентские страницы в виде полей скрытой формы, а затем впоследствии десериализуя эти объекты при возникновении страницы PostBack. Я потратил много дней на отладку определенного сайта на основе DNN, у которого были проблемы с "Недопустимым ViewState" только в некоторых браузерах, только на некоторых страницах и только в некоторые моменты времени. Что вызвало это? Через несколько дней я все еще не знал... отсюда почему я остаюсь в стороне от ViewState, если смогу. Тем не менее, я признаю, что это может быть несправедливое решение - в моем случае я работал с большим количеством стороннего кода, который генерировал динамические страницы и который создал много ViewState (размер и сложность ViewState на самом деле являются одной из моих причин для не используя WebForms вообще, если я могу).

Ответ 4

Как насчет использования сеанса..

Ответ 5

Например, если у вас есть несколько сервисов, вы можете использовать его как статичный, потому что не нужно, чтобы IIS создавал повторяющийся объект для сервисов, потому что все они одинаковы:)