Переменная хранится на Сессии, десериализованной однажды или многократно в течение жизненного цикла страницы?
Я хотел бы перенести Переменные сеанса в способ, подобный обсужденному на CodeProject.
public static class WebSession
{
private const string CurrentUserKey = "CurrentUser";
private static HttpSessionState Session
{
get { return HttpContext.Current.Session; }
}
public static bool Exists
{
get { return Session != null; }
}
public static User CurrentUser
{
get { return Session[CurrentUserKey] as User; }
set { Session[CurrentUserKey] = value; }
}
}
Вот мой вопрос: если я должен получить доступ CurrentUser многократно на той же странице, я получил бы повышение производительности путем присвоения его локальной переменной вместо того, чтобы получить доступ к переносящемуся свойству? Или делает HttpSessionState удостоверьтесь, что объект только десериализовывается однажды на запрос, так, чтобы последующие вызовы в том же запросе HTTP больше не стоили?
Спасибо, Aaron
4 ответа
Следуя предложению farktronix, мы использовали номера билетов Jira для аналогичных в mercurial, и я планирую продолжать использовать их для ветвей git. Но я думаю, что сам номер билета, наверное, достаточно уникален. Хотя может быть полезно иметь описательное слово в имени ветви, как отметил farktronix, если вы переключаетесь между ветвями достаточно часто, вы, вероятно, хотите меньше печатать. Затем, если вам нужно знать название ветви, найдите в Jira связанные ключевые слова в билете, если вы не знаете его. Кроме того, следует включить номер билета в каждый комментарий.
Если ветвь представляет версию, то общее соглашение заключается в использовании формата x.x.x (например, «1.0.0») для имен ветвей и vx.x.x (пример «v1.0.0») для имен тэгов (во избежание конфликтов). См. также: тэги
-121--1760762-Я столкнулся с проблемами, аналогичными проблемам Рубена в отношении ситуации выхода из системы/входа в систему. Лучшее рассуждение, которое я смог найти до сих пор, связано с тем, что WatiN запускает IE с помощью COM-сервера. Могут быть проблемы с утилизацией, но это целая другая Опра...
Что касается ситуации тайм-аута, то она происходит время от времени, но обычно появляется сообщение в консоли NUnit и продолжается. Одно большое различие, которое я вижу между вашей реализацией и моей, заключается в том, что я запускаю экземпляр IE как одиночный объект. Таким образом, мне никогда не придется закрывать и повторно открывать IE между тестами, и с тех пор я не испытывал проблемы выхода из системы/входа в систему. Следовательно, мои испытательные циклы короче, даже когда ИС виден и не работает в фоновом режиме.
-121--4690945-По каждому запросу имеется копия состояния сеанса в памяти. Поэтому единственная стоимость, которую можно было бы сохранить путем локального копирования переменной сеанса, - это стоимость приведения из объекта в тип. Копия в памяти затем добавляется к сеансу в конце запроса.
Сериализация и десериализация сеанса на странице зависит от выбранного поставщика сеанса. Для состояния сеанса in-proc сериализация не выполняется. Для серверов сеансов объект должен быть сначала сериализован.
Существует копия в памяти. Вы получаете незначительное улучшение производительности от кэширования стоимости; Это будет сохранять только поиск словаря, который будет слишком быстро, чтобы заметить, если вы не сделаете это времена Zillion на странице нагрузки.
Также важно отметить, что для данного ключа каждого поиска возвращает ссылку на тот же экземпляр, а сеанс тоже хранит ссылку. Это означает, что если вы извлекаете объект из сеанса и измените его, вам не нужно снова вызов сеттера, чтобы повторно сериализовать его.
Я просто задал вопрос об этом же: .NET .NET Summer Properties, когда-либо называемые неявно?
некоторые хорошие статьи для чтения
Я недавно протянул некоторую работу , и из того, что я мог видеть, весь объект государства десериализирован один раз и один раз только за запрос. Конечно, достаточно легко проверить - просто выделите ее дважды и проверьте ссылки .
Конечно, размещение значения в поле между использованием сэкономит некоторое время «поиск», но вы должны заплатить только за счет десериализации один раз.
Если вы действительно хотели быть уверены, что вы также можете передать это, реализуя , реализуемый и регистрация сериализации / десериализации вызовов.