Сессия против синглтон - PullRequest
6 голосов
/ 12 мая 2010

У меня есть веб-приложение, в котором я хотел бы извлечь пользовательские настройки из базы данных и сохранить их для глобального доступа. Имеет ли смысл хранить данные в объекте Singleton или Session? Какая разница между ними?

Лучше ли хранить данные как ссылку на объект или разбивать их на объекты типа значения (целые и строковые)?

Ответы [ 5 ]

11 голосов
/ 12 мая 2010

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

Идите и сохраните объект. Позвольте Сессии волноваться о сериализации этого к чему-то, что может быть восстановлено. Будьте осторожны с тем, что вы положили в сессию. Вы не хотите хранить там слишком много данных, или вы будете использовать много памяти (при условии, что кэш в памяти).

4 голосов
/ 12 мая 2010

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

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

2 голосов
/ 12 мая 2010

Объект сессии, определенно.

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

Сессии существуют на уровне пользователя. Это означает, что вы можете хранить данные для каждого пользователя, а не для процесса.

0 голосов
/ 20 мая 2016

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

Фон

Объект Session в ASP.Net может использоваться для хранения информации, относящейся к конкретному пользователю сайта. Сеанс индексируется по имени ключа, и когда он используется напрямую таким образом, это может привести к большому количеству отдельных имен сеансов. Альтернативный подход заключается в создании одноэлементного объекта для группировки связанных элементов и сохранения этого объекта с заданным именем ключа. «Синглтон» - это общий шаблон проектирования, который указывает, как обеспечить, чтобы в любой момент времени существовал только один экземпляр класса.

Преимущества одноэлементных сессионных объектов

  • Группировка элементов сеанса для организационных целей
  • Особенно полезно для серии страниц, посвященных переходным процессам, таким как регистрация на сайте. После завершения процесса объект может быть очищен от сеанса, чтобы можно было восстановить память (лучше использовать сервер ресурсы)
  • Анализ влияния изменений информации о сеансе намного проще
  • Определите области сайта, которые неправильно используют информацию (гораздо понятнее, чем просто использование имени переменной для определения целесообразности использования)
  • Intellisense для имен и типов свойств при доступе к объекту

Недостатки одноэлементных сессионных объектов

Сложнее увидеть количество отдельных предметов в сессии Результаты ASP.Net Trace не показывают значения внутри объекта Снижение производительности при использовании хранения состояния сеанса вне процесса (влияет на сериализацию)

Осуществление

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

public class singleton
{
  //Name that will be used as key for Session object
  private const string SESSION_SINGLETON = "SINGLETON";

  //Variables to store the data (used to be individual
  // session key/value pairs)
  string lastName = "";
  string firstName = "";

  public string LastName
  {
    get
    {
      return lastName;
    }
    set
    {
      lastName = value;
    }
  }

  public string FirstName
  {
    get
    {
      return firstName;
    }
    set
    {
      firstName = value;
    }
  }

  //Private constructor so cannot create an instance
  // without using the correct method.  This is 
  // this is critical to properly implementing
  // as a singleton object, objects of this
  // class cannot be created from outside this
  // class
  private singleton()
  {
  }

  // Create as a static method so this can be called using
  // just the class name (no object instance is required).
  // It simplifies other code because it will always return
  // the single instance of this class, either newly created
  // or from the session
  public static singleton GetCurrentSingleton()
  {
    singleton oSingleton;

    if (null == System.Web.HttpContext.Current.Session[SESSION_SINGLETON])
    {
      //No current session object exists, use private constructor to 
      // create an instance, place it into the session
      oSingleton = new singleton();
      System.Web.HttpContext.Current.Session[SESSION_SINGLETON] = oSingleton;
    }
    else
    {
      //Retrieve the already instance that was already created
      oSingleton = (singleton)System.Web.HttpContext.Current.Session[SESSION_SINGLETON];
    }

    //Return the single instance of this class that was stored in the session
    return oSingleton;
  }
}

Страница, которая хочет использовать этот объект, просто делает следующее:

singleton oSingleton = singleton.GetCurrentSingleton();
oSingleton.FirstName = "Robert";
oSingleton.LastName = "Boedigheimer";

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

public static void Dispose()
{
    //Cleanup this object so that GC can reclaim space
    System.Web.HttpContext.Current.Session.Remove(SESSION_SINGLETON);
}

Заключение

Существует много преимуществ использования одноэлементных объектов, хранящихся в объекте Session, вместо использования отдельных ключей сеанса для хранения информации. Это полезно для объектов, которые должны существовать в течение всего сеанса (группировка логических элементов, анализ воздействия, интеллектуальный анализ и т. Д.) И особенно для объектов, которые действительно нужны только в течение определенного периода времени на веб-сайте, пока пользователь не завершит конкретный процесс (намного проще определить неправильное использование переменных и сохранить ресурсы после завершения процесса, но сеанс будет продолжен).

0 голосов
/ 11 марта 2016

Иногда мне нравится метод ниже. Он заботится о проблемах с волшебными строками и неустановленными переменными сеанса. Он также запускает синглтон на уровне сеанса, а не на уровне приложения.

public static SessionHandler GetInstance()
    {
        if (HttpContext.Current.Session["SessionHandler"] == null)
        {
            HttpContext.Current.Session["SessionHandler"] = new SessionHandler();
        }
        return (SessionHandler)HttpContext.Current.Session["SessionHandler"];
    }

Тогда просто используйте его как обычный синглтон. Ввод нужных переменных.

...