Рекомендуемый шаблон для управления данными в объекте Session

Question

Мне нужно сохранить класс "POCO" в объекте Session.Какой шаблон вы бы порекомендовали с точки зрения хранения и производительности?(Я понимаю, что шаблон 2 требует сериализации).Спасибо.

Шаблон 1 (упрощенный):

class Location {
    string Country { get { return Session["Country"]; } set { Session["Country]" = value };
    string City { get { return Session["City"]; } set { Session["City]" = value };
}

Шаблон 2 (упрощенный):

class Location {
    string Country { get; set; }
    string City { get; set; }
}

Session.Add("Location", new Location() { ... } );

Answer 1

Если вам абсолютно положительно нужно использовать состояние сеанса, то я бы проголосовал за шаблон 2. Более отвратительно то, что происходит.

Но я, конечно, надеюсь полностью отговорить вас от использования состояния сеанса.Можете ли вы разместить что-то на странице, например, удостоверение личности или что-то, чтобы посмотреть, когда ответ возвращается?Вот почему:

• Состояние сеанса в веб-ферме является сложным.Возможно, у вас его сейчас нет, но ...
• Срок действия сеанса истекает, поэтому, если страница возвращается «позже», вам придется с этим справиться.
• Сессия использует ресурсы на сервере для посетителей, которых вы никогда не сможетесмотрите снова.

Так, может быть, вы можете сериализовать в viewstate?

Answer 2

Производительность (как вы заметили) будет лучше в шаблоне 1. Однако теперь у вас есть огромная зависимость от наличия сеанса - если этот класс когда-либо будет использоваться вне контекста Web приложение, тогда вам придется изменить его.

Answer 3

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

Использование одного объекта означает, что мне нужно обращаться к Session только один раз для каждого запроса.Хотя запрос одного простого элемента, такого как Session["City"], будет быстрее, чем получение моего относительно большого объекта, так как в любом случае мне нужно все это, я подозреваю, что один сделанный мной вызов будет быстрее, чем выполнение дюжины или более отдельных вызовов сеанса.

Кроме того, если я когда-либо изменю свой гаджет управления сеансом, у меня будет только два места для изменения кода (функции get и add)

Answer 4

Шаблон 1 лучше для производительности, но, как указал Харпер Шелби, сильно зависит от объекта Session.

Один из способов минимизировать эту зависимость - создать интерфейс для хранения и извлечения объекта сеанса. Ваша «реальная» реализация интерфейса будет вызывать сеанс по мере необходимости. Эта реализация интерфейса может быть предоставлена ​​вашему классу посредством внедрения зависимостей. Продолжая это, вы можете внедрить «поддельную» реализацию для целей модульного тестирования - нет необходимости использовать реальный сеанс там.

Answer 5

Я бы пошел с Pattern 2 только потому, что он чище.Добавление новых элементов в ваш объект Location не изменяет все вызовы Session.Add (objLocation) во всем вашем коде.

Если производительность является серьезной проблемой, тогда могут возникнуть проблемы с сериализацией, но мой опытбыло то, что память дешева, а большая фиксация - нет.Так что я бы пошел с Pattern # 2.