c # + WebForms + static - каковы лучшие практики?

Question

Я определенно не фанат WebForms, я предпочитаю в мире .NET ASP.NET MVC.

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

Я интегрирую EasyQuery.NET от Korzh.com.позволить конечным пользователям создавать свои собственные запросы SQL на основе заранее определенных моделей, сделанных удобными для пользователя с использованием псевдонимов.

Это актуально, потому что демо Коржа использует Global.asax для своей модели и класс запросов
вместе с Session.

Поскольку унаследованное приложение WebForms очень велико, Global.asax не используется
для элементов страницы.

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

Я обнаружил, что! IsPostBack не слишком надежен, и мне кажется, что
в WebForms лучше всего использовать Session.Проблема с
Session заключается в том, что он, похоже, передается клиенту с HTML и может вырасти
очень большим в килобайтах.

ВОПРОСЫ:

Поскольку статические переменные находятся на сервере IIS при использовании с WebForms, каждый пользователь приложения WebForms имеет одно и то же адресное пространство статических переменных?(Я думаю, что ответ да).

Каковы наилучшие практики / рекомендации по использованию / не использованию статических переменных в приложениях ASP.NET WebForms?

Спасибо.
С уважением,
Джерри (Лоури)

PS: Я не смог найти ответы
через Google или поиск SO.

Answer 1

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

public class Global : HttpApplication {
    public static string MyString
}

Из-за этого статическое свойство доступно для всех запросов, сделанных приложению. Не место для хранения специфичных для страницы предметов. Существует довольно много доступных механизмов хранения:

1. HttpRuntime.Cache и HttpContext.Cache, оба указывают на один и тот же экземпляр кэша, и элементы существуют в течение всего времени жизни приложения (поэтому имеют те же проблемы, что и статические экземпляры).

2. HttpContext.Items, специфичная для запроса коллекция элементов. Каждый запрос к приложению будет иметь свою собственную коллекцию предметов.

3. Сеанс HttpSessionState сохраняется для продолжительности посещения пользователя или всякий раз, когда он заканчивается. Это может быть настроено 4 способами:

   3.a. В ProPro сессионные объекты хранятся в памяти самим рабочим процессом. Быстрый доступ к кешу, не требует сериализации, но если приложение перезагружается, данные сеанса теряются.

   3.b. SqlServer, объекты сеанса сериализуются и хранятся в базе данных Sql Server. Требует, чтобы все сохраненные в сеансе элементы были сериализуемыми. Объекты сеанса сохраняются даже после перезагрузки приложения.

   3.c. StateServer, объекты сеанса хранятся в отдельном процессе и сохраняют данные при повторном использовании приложения.

   3.d. Пользователь сессионного провайдера, это ваше дело ...

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

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

Надеюсь, это поможет.