Блог

Всякий раз, когда мне приходится сохранять что-либо в сеансе, я приобрел привычку сводить к минимуму количество обращений к сеансу, делая что-то вроде этого:

 private List<SearchResult> searchResults;

private List<JobSearchResult> SearchResults
    {
        get
        {
            return searchResults ?? (searchResults = Session["SearchResults"] as List<SearchResult>);
        }

        set
        {
            searchResults = value;
            Session["SearchResults"] = value;
        }
    }
  

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

Зависит от того, какой тип хранилища сеансов вы используете (для получения дополнительной информации смотрите: здесь).

Если вы используете хранилище InProc, то разница в производительности, вероятно, минимальна, если вы не обращаетесь к объекту очень часто. Однако локальная копия на самом деле не повредит в любом случае.

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

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

Что касается производительности, я думаю, что в случае InProc выигрыш невелик или вообще отсутствует. Вероятно, аналогично любому другому словарю против хранилища переменных. Однако это может иметь значение при использовании других режимов хранения сеанса. И если вы действительно хотите знать, вы можете профилировать свое приложение и узнать;) Вы даже можете попробовать что-то столь же простое, как 2 записи трассировки и некоторое зацикленное чтение сеанса / запись между ними.

И вот информация о внутренних элементах хранилища сеансов: http://www.codeproject.com/KB/session/ASPNETSessionInternals.aspx

Это зависит от размера хранимых данных, пропускной способности (Интернет или локальная сеть), масштаба приложения. Если размер данных невелик, пропускная способность достаточно хорошая (локальная сеть), масштаб — всемирный (например Whitehouse.gov ), мы должны сохранить его на стороне клиента (как скрытый параметр формы). В других ситуациях (размер данных очень большой, пропускная способность очень низкая, масштаб небольшой (только группа из 3-4 человек будет использовать приложение), тогда мы можем сохранить его на стороне сервера (сеанс). Есть много других факторов, которые следует учитывать при выборе этого решения. Также я бы не рекомендовал вам использовать только одно поле в объекте сеанса. Создайте что-то вроде словаря (HashMap в Java) в сеансе и используйте его в качестве хранилища, и пользователь должен передать ключ этого словаря, чтобы получить эти данные. Это необходимо для предоставления пользователю возможности открывать ваш веб-сайт в нескольких вкладках.

Пример URL-адреса для доступа к необходимому поиску:

 http://www.mysite.com/SearchResult.aspx?search_result=d38e8df908097d46d287f64e67ea6e1a