Я использую широко статические переменные в своем проекте веб-приложений. Теперь я прочитал из некоторых статей, что это глобальная переменная для всего проекта, а данные, находящиеся в статических переменных, могут быть разделены или перезаписаны другими пользователями (я имею в виду, что это не зависит от пользователя или сеанса).
Так что вообще практика программирования не использует статические переменные в разработке обычного веб-приложения?
Статические переменные не используются вообще, как выражение GOTO/ключевое слово, существуют обширные ограничения на их использование и предпочтительно вообще не используются? Затем в каких случаях мы используем статическое ключевое слово?
Тогда у меня есть это требование, чтобы определенная переменная была инициализирована только один раз в определенном webform.aspx.cs, и область действия должна ограничиваться только этим конкретным .aspx.cs и тем конкретным пользователем, который зарегистрировался в? Как мне выполнить это требование? Если возможно, кто-нибудь проиллюстрирует это кодом?
Лично я стараюсь избегать статических переменных как можно больше. Они делают код трудным для unit test, а также могут вводить тонкие ошибки из-за одновременного доступа и условий гонки.
Что касается вашего требования, вы можете использовать сохранение переменной как свойство элемента управления в ViewState. Если это пользовательские данные, которые вы пытаетесь сохранить, вы можете использовать Состояние сеанса.
Я считаю, что ваша интерпретация static неверна.
Используйте статический модификатор, чтобы объявить статический член, который принадлежит типа, а не объект.
Другими словами, для всех конкретных экземпляров класса есть только один экземпляр этого элемента.
Нет ничего плохого в отношении статических переменных, если вы используете их правильно. Я считаю, что вы смешиваете статические с глобальными переменными. Доступ к глобальным переменным можно получить везде. Это нежелательно, поскольку знание того, когда и где задано состояние этой переменной, является сложным. Кроме того, это затрудняет тестирование устройства.
Этот вопрос Programmers.SE, вероятно, вас интересует.
В статике есть разные причины, по которым их следует избегать в целом, хотя они действительно имеют свои конкретные применения.
Тогда у меня есть это требование, чтобы определенная переменная была инициализирована только один раз в определенном webform.aspx.cs, и область действия должна ограничиваться только этим конкретным .aspx.cs и тем конкретным пользователем, который зарегистрировался в? Как мне выполнить это требование? Если возможно, кто-нибудь проиллюстрирует это кодом?
Для этого требования я бы предложил вам взглянуть на разъяснение требования:
Session, предоставляемый ASP. Пример кода для Session: http://msdn.microsoft.com/en-us/library/ms972429.aspxViewState на странице. Обзор ViewState http://msdn.microsoft.com/en-us/library/ms972976.aspxЛично я предпочитаю использовать Session - с ViewState, это очень легко для вещей, чтобы пойти не так, и когда они идут не так, это может быть очень сложно отладить!
объяснение: "когда они ошибаются, это может быть очень сложно отладить" - ViewState может быть настроен на работу несколькими способами, но в целом он настроен на работу, сериализуя объекты на клиентские страницы в виде полей скрытой формы, а затем впоследствии десериализуя эти объекты при возникновении страницы PostBack. Я потратил много дней на отладку определенного сайта на основе DNN, у которого были проблемы с "Недопустимым ViewState" только в некоторых браузерах, только на некоторых страницах и только в некоторые моменты времени. Что вызвало это? Через несколько дней я все еще не знал... отсюда почему я остаюсь в стороне от ViewState, если смогу. Тем не менее, я признаю, что это может быть несправедливое решение - в моем случае я работал с большим количеством стороннего кода, который генерировал динамические страницы и который создал много ViewState (размер и сложность ViewState на самом деле являются одной из моих причин для не используя WebForms вообще, если я могу).
Как насчет использования сеанса..
Например, если у вас есть несколько сервисов, вы можете использовать его как статичный, потому что не нужно, чтобы IIS создавал повторяющийся объект для сервисов, потому что все они одинаковы:)